-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yuppie wrote:
Hi!
Andreas Jung wrote:
--On 30. Mai 2006 10:17:08 +0200 Andreas Jung <lists@zopyx.com> 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. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com 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 iD8DBQFEfIV1+gerLs4ltQ4RAmZTAJ9OD8ZtUXtLBleT3jk4A58zs1JmIACgg/+s Pr6zpuj7T925flrWl6b3vjg= =7eBd -----END PGP SIGNATURE-----