[poppler] Fw: Rethinking poppler releases Poppler version = 0.18.4

[Ron]

Albert,

in the two years i've been following Poppler, I think youve been amazing.  A big THANKS is in order.  


I'm guessing that most of the Poppler users are using Poppler though Python or Ruby bindings.  I use Poppler through Ruby bindigs which are behind current release.    The current Ruby Poppler Gem 2.2.0 http://rubygems.org/gems/poppler

is using Poppler version 0.18.4     

http://ruby-gnome2.sourceforge.jp/hiki.cgi?Poppler#Poppler.version

 Therefore your way ahead of us Ruby users, I dont know about Python users.




What ever, or however the Poppler user base is accessing Poppler, a sustainable release cycle is necessary given the resources.   

I've been working on a Ruby PDF app using Poppler.

Looking at the time stamp of your e-mail, i guess your somewhere in Europe.   I'm in the USA.
Thanks



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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20140923/6cc9da95/attachment.html>