Re: [boost] Re: [1.33.0] Release schedule suggestion

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-04-02 14:11:14

On Apr 2, 2005, at 11:32 AM, David Abrahams wrote:
> Douglas Gregor <doug.gregor_at_[hidden]> writes:
>
>> On Apr 2, 2005, at 3:53 AM, Peter Dimov wrote:
>>
>>> Victor A. Wagner Jr. wrote:
>>>> I'll say this again.... if you branch, branch the development that's
>>>> NOT related to 1.33.0
>>>
>>> I'll agree again. The changes I check in when we are in release mode
>>> (have a release branch active) _always_ go to both the trunk and the
>>> branch. The branch doesn't help me in any way.
>>
>> Fair enough.
>
> Hey, this is a pretty radical idea.  None of the projects I've seen
> work that way, and it won't be possible to use this approach if we
> have to make a 1.33.1.  I'm not going to say flat out that it's the
> wrong approach, but at least there ought to be a loud announcement
> that we're thinking of turning the release procedure on its head.

 From a technical standpoint, there *must* be a branch in CVS to mark 
the 1.33.0 release. It needs to be there so that 1.33.1 can be based on 
something, as you said. I can't imagine any disagreement with the 
assertion that we need to have our releases stored as branches in CVS.

The difference between the two approaches is when that branch is 
created. In the traditional branch-then-stabilize-for-release model, 
the branch coincides with feature freeze: new features go into the 
trunk, only bug fixes go into the branch. In the model Victor and Peter 
are advocating, the branch coincides with the the release: the release 
manager branches the release and builds the release tarballs in the 
same step.

Those are the extremes. For any given project there is a particular 
point between those two extremes (inclusive!) that works best. GCC is 
at the branch-then-stabilize-for-release end of the spectrum, because 
they have a large number of contributors, maintainers, and subprojects 
that are continually evolving, so they need to separate out the 
"stabilizing" from the "further development". Lots of small projects 
are at the other end of the spectrum: the Parallel BGL, for instance, 
was released and then branched. There aren't any subprojects, there are 
few developers, and all developers are in the same building.

There are many factors that push the branch date earlier or later. As 
Peter says, making the branch earlier makes fixing bugs more tedious 
because one has to check things in on both branches. On the other hand, 
making the branch later means that developers have to either wait 
longer before adding new features or put those features on a branch. 
Perhaps there is just a simple relationship here: branching earlier 
encourages new features and further development, whereas branching 
later encourages stabilizing existing code.

There's one solution that everyone can agree on: if we can keep 
mainline CVS working well on all of our platforms and generally stay 
near the "zero regressions" mark, life will be better. The differences 
between the two extremes shrink because the time between freeze and 
release shrinks, so the penalties associated with branching "too early" 
vs. "too late" are decreased.

So, I don't want to pick a branch date now. Let's see how things go 
after we freeze on April 15th and shoot for that May 1 release date.

        Doug