Re: [boost] Release procedures?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-22 10:17:44

At 07:01 AM 1/22/2002, David Abrahams wrote:
 >
 >----- Original Message -----
 >From: "Steve M. Robbins" <steven.robbins_at_[hidden]>
 >
 >> Hello,
 >>
 >> I was a little surprised to read that moving CVS tags around
 >> is part of the release procedure.  That strikes me as rather
 >> error-prone.  It would be too easy to forget to move a tag,
 >> or move it to the wrong version.
 >
 >The theory is that once we have a feature freeze on a given revision, 
tags
 >would move relatively infrequently.
 >
 >> Then, once you've made this
 >> mistake, how do you revert it?
 >
 >Forgive me, there's probably something stupid about this question; can't
 >you
 >just move it back?
 >
 >Much later: Oh, I think I see your problem with this. If you move a tag 
and
 >forget where it came from there's no easy way to put it back.

I thought of that, and was assuming the release manager would save a 
working copy at the initial release tagging point, and so could always 
retag at that point.  Will that not work?  I guess I should test it first.

I also thought that if a tag got totally screwed up, we could just abandon 
it and retag at the current point in time.  Just restart the release 
procedure.  Hopefully that would be rare.  But it is in effect what we do 
now when we first start testing for release, but don't tag until later.

 >> [Some folks in our lab got burned by similar tag-moving
 >> procedures.]
 >
 >What, exactly, was the problem?
 >
 >> On Mon, Jan 21, 2002 at 03:12:44PM -0500, Beman Dawes wrote:
 >>
 >> > Release Procedure Overview
 >> >
 >> >   * Discussion on the main Boost mailing list to determine the target
 >date for
 >> >     initial release tagging of the CVS main trunk.
 >> >
 >> >   * Release manager performs initial release tagging.  Subsequent CVS
 >working
 >> >     copy updates for the tag retrieve the release candidate.
 >> >
 >> >   * Regression tests run on release candidate.
 >> >
 >> >   * Developers commit and retag fixed files.
 >> >
 >> >   * Repeat previous two steps until release manager is satisfied.
 >> >
 >> >   * Release manager rolls out the actual release.
 >>
 >> If you don't mind me saying, a more traditional release procedure
 >> runs like:
 >>
 >> 1. freeze the main trunk and tag head as a "release candidate 1"
 >>   - no features added until unfrozen
 >>   - developers can create a branch if they want to add features
 >>
 >> 2. regression testing
 >>
 >> 3. if not satisfied:
 >>    - fix bugs
 >>    - tag head as release candidate N+1
 >>    - go to 2
 >>
 >> 4. tag the head and unfreeze trunk
 >
 >We considered that possibility, but boost releases happen relatively
 >frequently and some libraries are under active development. It was felt
 >that
 >pushing all new development onto a branch every few weeks would create an
 >immense amount of busywork for active developers. On the other hand, 
fixing
 >a bug is a highly conscious act, and we have regression tests to tell us
 >whether we've gotten it right, so it seemed that moving a tag when you
 >address a bug report is not such a big deal.
 >
 >> CVS tags are not a limited resource!  Just keep adding
 >> release candidate tags as necessary, but never move or remove them.
 >> As a bonus, this scheme allows you to answer the question, "what
 >> changed between RC4 and RC6?" using CVS.
 >
 >It would be a good idea to have separate tags for different release
 >candidates.

It sounds like busywork to me, but see below.

 >And I can see the value in leaving fixed tags alone.
 >I guess that leaves us with branching the release track or branching all
 >development, and I would vote in favor of branching the release track.

If we do that, is there a way to do a commit that says "commit this change 
to both the main trunk and the release candidate branch?

If not, who is responsible for merging fixes back into the main trunk?  Or 
merging changes from the main trunk into the release branch?  How do other 
people typically ensure that the merge actually gets done?  Without 
becoming a time waster or administrative nightmare?

--Beman