Douglas Gregor <doug.gregor@gmail.com> writes:
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.
Technically, no. You could use a tag, and then branch from there. I don't neccessarily recommend it though.
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.
Whatever, it's still a pretty radical idea. That isn't the way we've been doing things, and it means people will have to be a *lot* more careful with checkins to the trunk during the release period. Everyone deserves at the very least a loud heads-up. -- Dave Abrahams Boost Consulting www.boost-consulting.com