Re: [boost] Release procedures?

From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2002-01-22 09:25:54

On Tue, Jan 22, 2002 at 07:01:08AM -0500, 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.

Yes, exactly.

 
> > [Some folks in our lab got burned by similar tag-moving
> > procedures.]
> 
> What, exactly, was the problem?

As you guessed, they moved tags around inadvertently and didn't
remember where they came from.  Remember that command-line cvs
commands are recursive by default, so if you type

        cvs tag -F blah
rather than
        cvs tag -F blah file.cpp

then you've just moved tag "blah" *on the entire subtree*!

That's the kind of slip that got made here, as I understand it.

That's why I'm scared to death of moving tags, or doing any "editing"
kind of CVS operation, e.g. "cvs admin".  Then again, I'm not a Boost
author, so discount my words as you see fit.

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

Sure, I can see the logic of this.  However, it is just a little
clumsy to use CVS in this way, IMHO.  CVS is better suited to
selecting the head of a branch as the release, rather than individual
files tagged in it.

As you noted, you could opt to branch the release rather than the new
work.  Alternatively, those eager-beavers can continue to work away in
their local sandbox and just refrain from committing any of their new
code until after the freeze.  One really only needs to commit to CVS
when the code needs to be shared with others.

Cheers,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants