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