Hi, 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. Thanks, Andreas
Andreas Jung 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.
I think we've had this discussion with Zope 2.9 already... I would prefer if we could make the branch now. Philipp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Andreas Jung 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.
I think we've had this discussion with Zope 2.9 already... I would prefer if we could make the branch now.
+1. Our policy says[1]: At the time the first beta of the new feature release is made, we create a new branch for that feature release (rooted at the trunk at the time the first beta is made) I'll make the branch if no-one else has, via the following command line (using the later revision from which the actual release tag was cut):: $ svn cp -r 68385 $ZSVN/Zope/trunk $ZSVN/Zope/branches/2.10 [1] http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess 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 iD8DBQFEfHXq+gerLs4ltQ4RAq9OAJ45hEfu28lNVpDLundQ3ZEYsJOHqQCgtlQl HApH5B7/uYw383oJOvoMhU4= =JNqN -----END PGP SIGNATURE-----
Hi! Tres Seaver wrote:
Philipp von Weitershausen wrote:
Andreas Jung 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.
I think we've had this discussion with Zope 2.9 already... I would prefer if we could make the branch now.
+1. Our policy says[1]:
At the time the first beta of the new feature release is made, we create a new branch for that feature release (rooted at the trunk at the time the first beta is made)
I'll make the branch if no-one else has, via the following command line (using the later revision from which the actual release tag was cut)::
$ svn cp -r 68385 $ZSVN/Zope/trunk $ZSVN/Zope/branches/2.10
[1] http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess
I would vote for a compromise: The branch should be created as soon as somebody wants to work on new features. As long as this is not the case the branch is just an extra burden and doesn't provide any benefits. Just my 2 cents. Cheers, Yuppie
--On 30. Mai 2006 10:17:08 +0200 Andreas Jung <lists@zopyx.com> wrote:
Hi,
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 :-) <http://svn.zope.org/Zope/branches/2.10/> -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
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). Cheers, Yuppie
--On 30. Mai 2006 19:25:06 +0200 yuppie <y.2006_@wcm-solutions.de> 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?
The policy is here: http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
-----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-----
Tres Seaver wrote:
yuppie wrote:
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.
You are arguing against a feature freeze policy for the trunk and I agree with you. But that is not what I propose. Often people don't *want* to check in new features for quite a while after the beta. And in that case I see the branch just as an unnecessary burden. Cheers, Yuppie
--On 30. Mai 2006 20:09:27 +0200 yuppie <y.2006_@wcm-solutions.de> wrote:
You are arguing against a feature freeze policy for the trunk and I agree with you.
But that is not what I propose. Often people don't *want* to check in new features for quite a while after the beta. And in that case I see the branch just as an unnecessary burden.
I think we have little need to discuss the policy at this point. I made the mistake to announce something different that was written down as policy... so it should be. -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
participants (4)
-
Andreas Jung -
Philipp von Weitershausen -
Tres Seaver -
yuppie