Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-03-04 09:14:28


At 06:45 PM 3/1/2003, David Abrahams wrote:

>Beman Dawes <bdawes_at_[hidden]> writes:
>
>> The tag is RC_1_30_0
>
>Didn't we agree that we were going to tag the trunk and generally do
>any merges from the trunk to the branch? This tag appears to be on
>the branch AFAICT.

OK, I've now gone back and read the entire thread. Here is a summary:

"Jeff Garland" <jeff_at_[hidden]> writes:

> It seems to me that part of the release process that would delay merges
> from the candidate branch to the main branch is misguided. Critical
> changes made to the release branch should be immediately merged on the
> main branch. This avoids the issues of forgetting to merge later
> which can lead to lost fixes or fixes that are much harder to merge.

At 05:46 PM 10/24/2002, David Abrahams wrote:

>I think the whole approach of merging from the release to the main
>trunk is totally misguided. If there's a fix which _can_ be applied in
>the trunk, it should be made there *first*. At least if it breaks
>something in the release candidate we'll be more likely to hear about
>it that way. If the trunk has already diverged too far for the fix to
>be applicable, it's a non-issue anyway.

No one disagreed with this assessment.

Jeff Garland posts a partially updated set of developer procedures:
http://aspn.activestate.com/ASPN/Mail/Message/1411802/release_procedures.htm

At this point the discussion fragments into details and corner cases. The
updated release_procedures.htm was never committed to CVS.

So, if we are going to do merges from the trunk to the branch for 1.30.0 we
need a finalized procedure right away. Jeff? Dave?

I'd really like it to include the Release Procedures for the Release
Manager, which is currently blank. While I understand the general idea, I'm
not sure what the release manager does differently. How is the branch
named? What is the tag that goes on the main trunk and how is it named?

Thanks,

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk