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 ;).


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to