[Zope3-dev] Release management refinements

[Philipp von Weitershausen]

Over the last couple of days we've been discussing Zope's new release 
cycle and the release management. I would like to sum up what seems to 
be the gist of those discussions:


9 month release period?
-----------------------

Several consumers of Zope releases have talked about their experience 
following the Zope release cycle. They apparently have a hard time 
following the six month cycle and seem to have adopted a 9 month cycle 
themselves. Not to mention that we just had a hard time producing 
something worthy of a "final" release.

I couldn't collect a negative vote for a 9 months release cycle, only 
that several people definitely don't want it to be longer than 9 months. 
  So, the obvious question is:

   Shall we release once every 9 months from now on?

In that case Zope 3.3/2.10 would be "on time" and Zope 3.4/2.11 would be 
scheduled for May, as Jim already suggested already.

Note that we do have the goal to "explode" Zope 3 into more independent 
pieces. It is conceivable that these pieces might gain their own release 
cycles in the future. Things like zope.interface may not change at all 
over periods of years whereas other packages might see much more active 
development. Of course, we're not there yet, so a 9 month cycle would 
apply to all of Zope 3 for now, and perhaps even after the "explosion" 
we might keep a 9 month cycle for most packages because of Zope 2.


Zope 3 bugfixes
---------------

Up until now, the last stable release (currently Zope 3.2) was not 
maintained properly in terms of bugfixes. This is an unacceptable 
situation. I know a fair number of people who are doing Zope 3.2 
deployments now, not to mention Zope 2.9 which includes Zope 3.2 and 
enables a lot of functionality already.

In the Zope 2 world, the following rule has proven to work quite well:

1. Fix the bug in the *oldest* maintained branch (e.g. Zope 2.8 still)

2. Merge the bugfix to newer release branches (e.g. Zope 2.9 and 2.10)

3. Merge the bugfix to the trunk

It seems to be the common consensus that this practice should now also 
be applied to Zope 3. That means, bugs are to be fixed in Zope 3.2 
first, then in Zope 3.3, and then the trunk.

Unless there are any objections, we should now be enforcing this rule! 
Furthermore, if you've fixed a bug in Zope 3.3 over the last months and 
haven't backported the fix to Zope 3.2 yet, please do so soon.


Release management
------------------

We'll need people who will manage releases. The problem isn't as much in 
physically making the releases (tarball, etc.) but to bug people to fix 
release critical bugs. I'm thinking collector maintenance, bug days, and 
lots of nagging here. If I had organized the two Zope 3.3 bugdays a bit 
earlier, perhaps the release could've been out earlier...

Andreas Jung is heroically managing all Zope 2 releases, though he does 
have lots of help from others. For a long time, Chris Withers has 
organized bug days, for example. As for Zope 3, Martijn has stepped up 
to take over the Zope 3.3 line, I'll be maintaining the Zope 3.2 branch 
in terms of releases. Of course, most bugfixes apply to both branches, 
so bug days will benefit both of them. The important thing is that we do 
get the bugs fixed and maintenance releases for stable branches out there!

We'll also need a release manager for the next release line (Zope 3.4). 
As far as I see the RM's job it mainly involves nagging people so that

a) feature freezes can be made in time (and thus beta releases),

b) release critical bugs are fixed soon after they're discovered (and 
thus won't hinder subsequent beta or final releases)

c) non-release critical bugfixes won't find their way into the release 
branch during the release-candidate period.

Whether or not Theuni has signed up for this job I can't really say. 
It'd be great, though ;).


Thoughts?