[Zope-dev] Stable / Development branches?

[Chris Withers]

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