[poppler] Rethinking poppler releases

[Albert Astals Cid]

El Dijous, 25 de setembre de 2014, a les 06:52:59, jose.aliste at gmail.com va 
escriure:
> Hey Albert, if you think it wont be much more burden for you at making the
> releases, then please go for it. Having more releases make for easier
> synchronization with KDE and GNOME schedules. Other than that, we could
> also try to put a schedule every x months that is sync with KDE and GNOME
> (and other desktops if necessary) so features needed for okular and evince
> can be pushed sooner than later.

The thing is, we already do a monthly release, but it's bugfix only, that 
delays features for a long time and at some points puts lots of effort in doing 
releases since I need to do the betas and rc for the next one while doing the 
other releases, what i'm aiming is just at a simpler relase schedule that 
gives me/us less work.

Cheers,
  Albert

> 
> 
> Greetings
> 
> 
> José
> 
> On Wed, Sep 24, 2014 at 4:38 PM, Albert Astals Cid <aacid at kde.org> wrote:
> > El Dimecres, 24 de setembre de 2014, a les 02:15:49, Maciej Mrozowski va
> > 
> > escriure:
> > > On Wednesday 24 of September 2014 00:51:06 Albert Astals Cid wrote:
> > > | Hi all, we released 0.26.0 five months ago. And we have no schedule
> > > | for
> > > | 0.28.0 (or i can't find no email discussing it).
> > > | 
> > > | This is something that has been happening repeateadly, we "forget"
> > > | when
> > > | the
> > > | next feature release or we need to delay it because we only release it
> > > | every so often and we *really* need a feature in.
> > > | 
> > > | I'd like to propose a change from having bugfix releases every month
> > 
> > and
> > 
> > > | feature releases every ~6 months to just having a release every month.
> > > | 
> > > | In that release we would introduce both bugfixes and features.
> > > | 
> > > | We have been *very* good in the past with not introducing regressions
> > > | thanks to running the regression suite, so i think this is a good
> > > | thing
> > > | since it makes it easier for our features to reach the users earlier
> > > | (e.g. i have a feature in poppler-qt that need to be released to make
> > > | okular faster).
> > > | 
> > > | The downside is that some distros won't like it, but honestly those
> > > | distros
> > > | already don't update some of the minor releases because we do changes
> > 
> > to
> > 
> > > | our internal APIs so one can't fix distros.
> > > | 
> > > | Given the manpower we have at the moment (i.e. very low) i think a
> > 
> > monthly
> > 
> > > | release (or maybe every two months) that contains both bugfixes and
> > > | features is the best for us.
> > > | 
> > > | Comments?
> > > | 
> > > | Cheers,
> > > | 
> > > |   Albert
> > > 
> > > Sorry for maybe missing something obvious, but how about just releasing
> > 
> > when
> > 
> > > you feel there's something warranting the release instead of sort of
> > > forcing yourself to do release cycles?
> > 
> > Timed releases are the best for us, solves us from the issue of thinking
> > "do
> > we have enough to release?", yes we do because it's time.
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > While a little bit orthogonal, this could also involve choosing
> > > different
> > > versioning method[1]. Patch releases whenever important enough fixes are
> > > delivered (so that distros don't have to backport them from git).
> > 
> > Introduce
> > 
> > > major releases for "important" changes, minor releases for maybe less
> > > "important", but preferably API backward compatible changes. "important"
> > 
> > is
> > 
> > > differently defined by different parties. For distros it could mean
> > > "anything that breaks API or considerably enhances functionality".
> > 
> > Poppler
> > 
> > > is somewhat known for changing internal (XPdf?) API more than once so -
> > > following distros' "important" definition - that could mean numerous
> > 
> > major
> > 
> > > releases if that API is considered public API, but hey..
> > > 
> > > 1. http://en.wikipedia.org/wiki/Software_versioning#Change_significance
> > > 
> > > regards
> > > MM
> > > _______________________________________________
> > > poppler mailing list
> > > poppler at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/poppler
> > 
> > _______________________________________________
> > poppler mailing list
> > poppler at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/poppler