[poppler] Rethinking poppler releases

[Albert Astals Cid]

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