Martijn Faassen wrote:
Chris Withers wrote:
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
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
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?
Simplistix - Content Management, Zope & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -