On Apr 2, 2005, at 11:32 AM, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> 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