Date: Tue, 10 Apr 2001 21:30:40 -0700 From: Dima Dorfman <dima@unixfreak.org> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: sjt@cisco.com (Steve Tremblett), freebsd-stable@FreeBSD.ORG Subject: Re: Releases Message-ID: <20010411043041.07F373E09@bazooka.unixfreak.org> In-Reply-To: <200104101534.IAA35432@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on "Tue, 10 Apr 2001 08:34:25 -0700 (PDT)"
next in thread | previous in thread | raw e-mail | index | archive | help
"Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> writes:
> The tag sequences could be better documented, or err, the newvers.sh
> changes that occuring during the phases could be better documented.
Attached is something that resembles a first attempt at this.
Essentially, it's the admin.html#RELEASE-CANDIDATE FAQ question but
with more detail. It's not meant as an extensive guide, but rather a
summary of what happens and some appropriate rationale. The FAQ entry
is great, but I think something with more detail is in order.
I'm not quite sure where this should go. It seems redundant and too
long for the FAQ, but it's not quite an article, although I guess I
could add some more to it to make an article about "The FreeBSD
Release Cycle". At the very least it's a summary of the majority of
the anti-BETA threads.
Comments and suggestions welcome.
Thanks,
Dima Dorfman
dima@unixfreak.org
How -STABLE becomes -RELEASE
Minor releases, i.e. releases where the minor version number is
greater than zero, are tags, or points, on the RELENG_X branch
corresponding to their major version number. Before a release is
made, the branch its being cut from goes through a ``code freeze''.
A code freeze is the state in which all changes to the respective
branch must be approved by the release engineer before being committed
{XXX footnote explain 'commit'}. During the code freeze, the branch
is renamed from ``-STABLE'' to ``-BETA''. There are two reasons for
this seemingly unreasonable change:
1. Right before the code freeze (a few days), a lot of
changes--fixes and others--are merged from -CURRENT (``MFC'd''). This
isn't an intentional part of the release cycle; it just so happens
that developers wait until the day before the freeze to merge the
changes they want in the release (and since this is a volunteer
project, we shouldn't ask them to do otherwise). Thus, the quality of
the code right before the code freeze is slightly impaired.
2. Some ports break in mysterious ways when the version of the
system changes (e.g., 3.1 becomes 3.2). It is desireable that the
ports as shipped with the release work properly, so they must be
tested on a system as similar to the one being release as possible;
bumping the version number is just another way to catch some rather
silly and easy-to-correct errors. Also, since the ports collection is
collectively maintained by over 500 {XXX is this right?} people, it
would be unfair to ask them to manually change the version number
themselves simply for testing the ports.
The branch remains in the code freeze anywhere from a few weeks to a
month. As the code freeze draws to a close, and the release to its
due date, the branch is renamed from ``-BETA'' to ``-RC''. RC stands
for release candidate. Anything marked as a release candidate may
eventually become the release without any changes (modulo the branch
name). Depending on how many changes do occur in this state, there
may be multiple release candidates. These are represented as ``-RCx''
where x is the number of the release candidate.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010411043041.07F373E09>