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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk