[Zope3-dev] RFC: Release cycles

[Philipp von Weitershausen]

Hi all,

the recent discussion about future Zope3 releases worries me. Here's an 
informal proposal for settling this:

Goals

As Zope3 developers we want

 - to take our time developing the software (speed kills!)

 - provide good quality software

As consultants with customer projects, we also want

 - good release management with a reliable release cycle

 - code that is contributed showing up in releases a.s.a.p.

Proposal

I think these two sets of interest don't have to be exclusive. Statements on 
this list predict a year until X3.1 is released. I don't think it has to take 
that long (though I'm not saying we should rush this release). I really think 
that X3.1 could and should be delivered quite soon -- it's just a matter of 
defining what X3.1 is.

Many things have been planned for X3.1. Stephan has already tackled one of the 
big tasks, ImplementViewsAsAdapters; other minor improvements that didn't make 
it into X3.0 are also already sitting in trunk or about to be committed. 
However, other things that were originally planned for X3.1 have not even been 
thought through properly (correct me if I'm wrong), like local configuration 
through ZCML. I see no reason whatsoever holding off X3.1 for them; why 
couldn't they go into X3.2, X3.3, etc., when they're ready?

I suggest to adopt a release management similar to Debian's (except that they 
take ages for new releases which we don't want). A short period of time after a 
certain version is released (e.g. X3.0), the next version (e.g. X3.1) should be 
branched off from the trunk. At that time the branch is under a feature freeze 
like the X3.0 branch was when it was branched off. The trunk will be open for 
new features as usual.

What this proposal is not

This is purely a proposal regarding when to branch, when to release and what to 
put in which branch. I'm NOT proposing to change any of the quality assurance 
measurements we've been taking, including the actual speed of development on 
certain features. Taking time to find use-cases, write proposals, implement and 
test features is still important! My concern is just that features needing this 
much time would hold off releases of otherwise releasable features.

I'm also not proposing to set a specific time period that a release cycle 
should take. Quality code takes time and that's ok. It is all about getting 
already implemented features out. However, I imagine that X3 releases could 
happen every 6 months or so, but that's just an estimate.

Advantages

 - shorter release cycles

 - new features appear in releases quicker

 - contributors get to use features that they implemented earlier

 - changesets from one version to another are smaller, making transitions
   smoother; that would also be a lot easier on 3rd party developers who
   need to adjust their software when new versions are released.

 - legacy code for backward compatability can be removed sooner

Disadvantages

 - more overhead for the developers (though I think this is marginal if at all
   existant; I expect not more than two branches [trunk and to-be-released
   branch] to be active at a time, so it'd be just like now.)

 - probably need a release manager


Those who are involved into Plone I'd like to remind about the 2.0 release. 
Initially a 1.1 release was planned after 2.0. It provided a relatively small 
set of improvements. Before someone could put his foot down, lots of stuff was 
checked in and 1.1 started to blow up. Initially a 1.1 release was planned for 
September 2003; 6 months later, in March 2004, it was released, but as 2.0 
because of the many additions. Many people who based their business on Plone 
and needed something like 1.1 in late 2003 (including me) critized the release 
management. Everyone learned their lesson and Plone now has an official release 
manager.

Another good example from Zope's own history is be the release of 2.7, though I 
think this one took so long for several different reasons (I frankly don't 
remember). Fact is that now with Andreas being the release manager, 2.7 bugfix 
releases are popping out regularly...

Looking forward to your comments,

Philipp