From: David Abrahams (dave_at_[hidden])
Date: 2005-04-02 18:55:01
Douglas Gregor <doug.gregor_at_[hidden]> writes:
> 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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk