Re: [boost] Release procedures?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-22 07:01:08

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

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

-Dave