[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]