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?
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
