[Zope-dev] Re: 2.10 branch and trunk

[yuppie]

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