Martijn Faassen wrote:
Chris Withers wrote: [snip]
Personally, I find non-time-based releases a much nicer prospect: you only need to move to the next major version when it's ready and because it contains big new features you really want.
Who is going to develop these big features? What's the motivation? I'm not going to develop major features if I know it might be a year or more before I can actually get to use them.
Maybe there's something to be said for the "stable/development" branch split that linux has, or something similar? Even numbered releases are "feature add" releases: 2.12.0 - "okay, lets start adding features" 2.12.1 - "whoops, fixed bug x" 2.12.2 - "added feature y" 2.12.3 - "whoops, fixed bug z" 2.12.0 - "added feature z" 2.14.1 - "whoops, fixed bug a" Odd numbered releases are "stable" releases: 2.13.0 - "we're happy that all features up to y are stable" 2.13.1 - "whoops, fixed bug z" 2.13.2 - "whoops, fixed bug a" Using this model, there's at most 2 actively maintained branches, which is the big win for me right now. For bug #2016, Tres had to patch 4 different ZODB branches and then re-point 4 different svn:externals. With what I propose above, the number would be at least halved in both cases. People like Martijn could track the even releases, get all the new features, etc. People like me (when I have my "stable projects" hat on) could track the odd releases and not worry about stuff breaking every few months. I'd see the move that created 2.13 above to be a "big deal", maybe once every year or two, but one where there should be a well-tested and documented migration path from the last stable release. I dunno, I'm not saying the above is spot on, but maybe something we should think about? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk