Re: Continued development during release process

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 21 Apr 2006 14:37:13 -0700
> From: Bill Wohler <wohler@newt.com>
> Cc: mh-e-devel@lists.sourceforge.net
> 
> First of all, if you're handling the release, including tagging and
> stuff, please let me know who you are.

That's not me, and AFAIK no one has stepped forward to volunteer for
the job yet.

> Second, once you add a pretest tag, will you make subsequent tags based
> upon that tag, or will you simply tag the trunk?

I don't really understand the question, so maybe what's below won't
answer it; sorry.

When the pretest is under way, at some point a release-candidate
branch is created.  (I say ``at some point'' because I don't think
there's an agreement whether this should happen right away when the
pretest starts, or later, much closer to the release itself, i.e. at
pretest end.)  This branch is used for the initial release, in this
case for version 22.1, and for all subsequent bug-fix releases that
(at least ideally) fix bugs without introducing major features; these
would be versions 22.2, 22.3, etc., until it is decided by The Powers
That Be that it's time to make another release from the trunk.

If the release branch is _not_ cut as soon as the pretest starts, the
trunk is frozen for anything but bugfixes from the pretest start and
until we branch.  As soon as the branch _is_ cut, it is possible to
resume development commits to the trunk, in parallel with fixing bugs
on the release branch.  (One of the arguments _against_ branching
early is that, given the relatively small number of core developers,
opening the trunk for development might leave too few people to
actively work on fixing bugs on the branch.)

Having said that, a caveat: the above is based on my limited
experience with one of the 21.x releases.  That was a long time ago,
so it's possible that for the upcoming release the procedures will be
different.  AFAIK, this was never seriously discussed, because doing
so far from the pretest is a largely academic dispute.  In any case,
whoever volunteers for the job will have an important say on how the
release process is managed.

HTH