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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
