Re: [boost] Release procedures?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-29 14:44:55

At 02:52 PM 1/28/2002, David Abrahams wrote:

 >The command-line instructions are essentially the same as the detailed 
ones
 >I posted in response to your request,

I don't want to hurt your feelings, but I found the other set of 
instructions easier to follow.  Perhaps that's just because I had already 
done a number of experiments by the time I read them.

 >   except that:
 >
 >1. Mine didn't deal with the multiple merge issue (easy modification)

But IMO this is the trickiest issue, so needs to be treated carefully.

 >2. These gloss over the "make sure it builds step", which in general 
isn't
 >possible without either checking in /everything/ you've got and tagging 
it
 >so you can get it back, then checking out everything on the release
 >candidate branch, or using a separate copy of the CVS tree like I
 >suggested.

The problem is that the most appropriate approach is very situational.  For 
example, the "separate copy of CVS tree" work well for developers with a 
high speed Internet connection and a simple change that doesn't require 
more that a few tests to validate the change.  If either of those isn't 
true, it may not be the preferred approach.  Thus we really need a better 
indication that there are several possible approaches.

 >3. These are a lot less explicit.

I guess that's a matter of taste.  I found the intermixed prose and cvs 
commands to be harder to follow than just the annotated cvs commands.

But if you want to try to improve it, feel free.  The important point is 
that we now know how (in terms of branch candidates, and so forth) we want 
the release procedure to work, so we can go ahead with a release.

 >It seems to me that it might be better to integrate the multiple merge
 >instructions into what I already wrote.

I considered that, and decided that it wouldn't be useful to try to hide 
the cvs distinction between a first merge and subsequent merges.  But if 
you think you can improve the wording, please go ahead and change it.

--Beman