[boost] Re: Changes to release procedure

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-10-01 09:15:06

David Abrahams wrote:
> 
> 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?

Maybe a cvs guru can shed some light on this... Anyone out there?

> > > 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.

Ok, I understand now. So maybe we should allow both ways.

Markus