From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: Continued development during release process
Date: Sat, 22 Apr 2006 13:35:56 +0300 [thread overview]
Message-ID: <umzedyk1f.fsf@gnu.org> (raw)
In-Reply-To: <2167.1145655433@olgas.newt.com> (message from Bill Wohler on Fri, 21 Apr 2006 14:37:13 -0700)
> 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
next prev parent reply other threads:[~2006-04-22 10:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-21 21:37 Continued development during release process Bill Wohler
2006-04-22 10:35 ` Eli Zaretskii [this message]
2006-04-23 16:01 ` Bill Wohler
2006-04-23 20:59 ` Kim F. Storm
2006-04-24 2:38 ` Bill Wohler
2006-04-22 22:32 ` Richard Stallman
2006-04-23 14:10 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=umzedyk1f.fsf@gnu.org \
--to=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).