-----BEGIN PGP SIGNED MESSAGE-----
> Andreas Jung wrote:
>> --On 30. Mai 2006 10:17:08 +0200 Andreas Jung <[EMAIL PROTECTED]> wrote:
>>> I plan to create a branch for Zope 2.10 after 2.10beta 2 or short before
>>> the 2.10 final release. This means that the Zope trunk should only be
>>> used for bugfixes *only* until the branch is cut. So no new development
>>> and feature should happen on the trunk until then..Use your own branch
>>> until the trunk is open for new stuff to appear in Zope 2.11.
>> As Tres pointed out we do have a policy for branching so the 2.10 has
>> been created. Feel free to mess up the trunk :-)
> Who made up that policy? And why?
> I don't think it's a good policy. It is very unlikely that people want
> to mess up the trunk right after the first beta. I'd prefer a policy
> like that::
> After the first beta of the new feature release is made, we
> create a new branch for that feature release as soon as necessary
> (rooted at the trunk right before the first non-bugfix checked in).
The purpose is to allow feature development for the next release to
proceed without risking or interfering with the beta. The whole point
of the release branch is to insulate the release process from such
changes: it *is* the point where the release manager actually has the
power to veto / release changes. The trunk is not really under the
release manager's control.
For a nice example of why *not* to freeze the trunk during a beta, have
a look at the mess made during the ZopeX3 release cycle, where the trunk
was feature frozen for *months* as an explicit act of policy (the RM was
basically trying to coerce developers into fixing "release critical" bugs).
Bugs which affect the release during the release cycle should be fixed
on the release branch, and forward ported to the trunk if applicable.
That is a slight amount of extra work, but well worth the reduction in
the "bottleneck" on the trunk.
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -