[poppler] Rethinking poppler releases

Maciej Mrozowski reavertm at gmail.com
Tue Sep 23 17:15:49 PDT 2014


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


More information about the poppler mailing list