Date: Sun, 07 Sep 2003 18:44:08 -0700 From: underway@comcast.net (Gary W. Swearingen) To: Michel Talon <talon@lpthe.jussieu.fr> Cc: freebsd-chat@freebsd.org Subject: Re: The Old Way Was Better Message-ID: <4k7k4kjbpz.k4k@mail.comcast.net> In-Reply-To: <3F5B4AA9.1000003@lpthe.jussieu.fr> (Michel Talon's message of "Sun, 07 Sep 2003 17:11:37 %2B0200") References: <3F5B4AA9.1000003@lpthe.jussieu.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Michel Talon <talon@lpthe.jussieu.fr> writes:
> In my opinion, the 4.* series should not
> have been maintained so long (except for security fixes), it stresses
> too much the available developer workforce.
So when should non-security 4.* work have stopped? When I started
using FreeBSD, the 5.0 target was Nov'2001, IIRC, and it was supposed
to have features than are not yet in 5-CURRENT. How long should 4.*
users have to live with a moribund OS? I don't know, but the shorter
the time, the less reason there is to stop MFCing. IMO, it's more
important to protect FreeBSD's reputation for stability than to
advance 5.*-STABLE by a few months by abandoning 4.* users in any
obvious way.
I'm not prepared to say what developers "should" have done except that
they should have made better schedule estimates, something much easier
said than done. I suspect that 5.0 & 5.1 should have had fewer new
features, but I couldn't make a convincing case for it.
I WILL give one confident "should": They should heed Bill's comments
regarding the importance of marketing -- even marketing to existing
FreeBSD users. If developers must, they could keep the current CVS
tag-naming scheme and use whatever terms they want in developer
forums, but elsewhere FreeBSD people should use more sensible terms
than CURRENT (other branches are current too) and RELEASE (other
branches are releases too) and STABLE (which might not even compile).
I'd extend Bill's suggestion for future branch naming to:
ALPHA -- Name of the HEAD branch (trunk?).
(Was: CURRENT.)
#-ALPHA -- Synonym of ALPHA.
(Was: #-CURRENT.)
(Non-existent after HEAD moves on to #+1.)
BETA -- Ambiguous synonym of #-BETA, but useful in context.
(Was: STABLE.)
#-BETA -- Name of the RELENG_# branch.
(Was: #-STABLE.)
(Non-existent until #.#-STABLE is created.)
(Example: 4-BETA = RELENG_4)
#.#-BETA -- Name of the RELENG_#_# branch, when beta quality.
(Uncommon. Example: 5.1-BETA = RELENG_5_1)
#.#-STABLE -- Name of the RELENG_#_# branch, when stable quality.
(Common. Example: 4.8-STABLE = RELENG_4_8)
#.#.#-* -- Name of the RELENG_#_#_#_RELEASE branch, where
"*" equals BETA or STABLE.
(This is more of a node than a branch, AFAIK; such
branches have only one snapshot which is normally
called a "release". ALPHA might never be used.)
(Example: 5.1.0-BETA = RELENG_5_1_0_RELEASE)
(Example: 4.6.2-STABLE = RELENG_4_6_2_RELEASE)
Releases and snapshots could be similarly named (though snapshots can
only be identified by branch name and a date+time, AFAIK). It's
debatable whether the names of branches and releases should contain
something like "BRANCH" or "RELEASE" so they are not ambiguous.
Using, say "#.#-STABLE" as a synonym for "#.#.0-STABLE" should
probably be allowed for releases (only).
It might reduce transition confusion to use a term other than
"STABLE". Maybe "TESTED". Alternatives to mix and match:
CURRENT STABLE sucurity-fix-only
ALPHA BETA STABLE
EXPER DEVEL TESTED
P.S. For an example of confusing names, one need go no further than
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/5-roadmap/schedule.html
which suggests a series of branches like this:
Sept 1, 2003: 5.2-BETA, general code freeze
Sept 15, 2003: 5.2-RC1, RELENG_5 and RELENG_5_2 branched
Sept 22, 2003: 5.2-RC2
Sept 29, 2003: 5.2-RELEASE
So the -STABLE branch starts two weeks before there's a stable release.
And releases with "5.2" in the name come out before the first good
5.2 release and even before a 5.2 RELENG_ branch starts. And releases
are called release "candidates", even though they are actual releases.
And when they are not candidates to be released for wide use. Bedlam!
I'd use something like (ignoring the dates):
Sept 1, 2003: 5.1.1-BETA (tag RELENG_5_1_1_RELENG), general code freeze
Sept 15, 2003: 5.1.2-BETA (tag RELENG_5_1_2_RELENG)
Sept 22, 2003: 5.1.3-BETA (tag RELENG_5_1_3_RELENG)
Sept 29, 2003: 5.2-STABLE (tags RELENG_5_2_0_RELENG, RELENG_5_2, RELENG_5)
I see no need to designate release branches or releases as release
candidates. If they are indead candidates to become other releases,
they can be designated so in words. If such designations MUST be
encoded in the name, then add some token which is as non-misleading as
possible, as in
Sept 22, 2003: 5.1.3-BETA-P2 (tag RELENG_5_1_3)
Sept 29, 2003: 5.2-STABLE (tags RELENG_5_2_0_RELENG, RELENG_5_2, RELENG_5)
which has a beta-quality "Prerelease #2" becoming a stable release.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4k7k4kjbpz.k4k>