[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-poppler
Subject:    Re: [poppler] Rethinking poppler releases
From:       Maciej Mrozowski <reavertm () gmail ! com>
Date:       2014-09-24 0:15:49
Message-ID: 4112037.y9L32LSGWF () lebrodyl
[Download RAW message or body]

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?

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler


[prev in list] [next in list] [prev in thread] [next in thread]