Re: [boost] Re: Changes to release procedure

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-01 08:13:44

From: "Markus Schöpflin" <markus.schoepflin_at_[hidden]>

> David Abrahams wrote:
>
> > I'd like to propose the following changes:
> >
> > 1. The entire release candidate branch should be tagged with
> > RC_whatever_last_merge immediately after the branch is created. That
can be
> > a big help when multiple changes need to be merged back into the trunk,
> > because you can just do:
> >
> >     cd $BOOST_ROOT
> >     cvs update -jRC_whatever_last_merge -jRC_whatever
>
> Doesn't the flag -f do what you want event without tagging the release
> branch after creation?
>
> cvs update -f -jRC_whatever_last_merge -jRC_whatever

I don't know, does it?

> > 2. There should not be a strict rule that patches go into the release
> > branch before they go into the main trunk. In fact, if anything it
should
> > go the other way. Shouldn't some changes get a chance to be tested "in
> > situ" before we make a change to the release candidatee, which is
supposed
> > to be more stable than the trunk?
>
> I don't follow your reasoning that it should go the other way. If you
> find a bug in the release branch you should fix and test it in the
> release branch and then merge it to the main trunk. This makes sure that
> the fix doesn't break anything in the release branch.

Some fixes are more-risky than others. For example, Rene made some changes
to the build system to make the "stage" rule actually work as expected
(thanks, Rene!) However, he was only able to test these changes on the
compilers he had available to him. It might have been best to let that
patch live in the trunk a while to see if it broke anything before putting
it in the release candidate.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com