Version nomenclature [was RELENG_7 to 8]

grarpamp grarpamp at gmail.com
Sat Aug 15 05:48:29 UTC 2009


Wanted to put in a suggestion. Users are constantly confused and
asking questions about the FreeBSD version naming scheme, somehow
not quite picking it up right, which is which, where to use it,
etc.

And though I know what it is, it still seems silly to me.  Because
we've got logical pointers _loosely_ correlating to formal repo tag
and branch names.  Worst case I've seen was when FreeBSD had 4, 5,
6 all in flux at once.  STABLE and CURRENT could only point to two
things and there were about 10 potential tags involved.

Basically, I'm proposing FreeBSD should relegate the terms STABLE
and CURRENT out to the marketing portion of the web team. You
can't check them out of any repo as tags, 4 and 5 were 'stable' when
6 was 'current' and so on.

CURRENT means nothing more than cvs HEAD or svn trunk or git <nonce>.
So use those terms instead of leading people think they can check
out 'CURRENT' or that it has some magical command line, config file
or source properties.  website: 'The latest snapshots from our
FreeBSD-STABLE and FreeBSD-CURRENT branches are also available'...
checking out those branch names gets you HEAD. There are references
to 7-STABLE, 8-CURRENT and parhaps other bastardizations on a theme
:-) in the handbook that are not valid tags.

STABLE is pretty much the same way, only more confusing if more
than one thing is 'stable'.  Back in the 4/5/6 days it could have
referred to any number of branches.  And on the main page, we now
have more buzzwords...  'production' and 'legacy'.  In fact, I'd
venture that the proper place for such words,
CURRENT/STABLE/production/legacy, is only on the release/download/support
related pages of the website, with little '->'s to the actual tag
they imply. More importanly, with descriptions that say something
like which trains are developed/supported when, for how long. ie:
why the deserve such words to be applied to them.

Anyone who has a need to refer to CURRENT/STABLE is obviously getting
beyond the release iso's and into the cvs/svn/git level of things.
So just use the right terms then.  Encourage people to use proper
tags and for reporting bugs and things. They could probably make it
into uname somehow.

RELENG_x_y_RELEASE
RELENG_x_y [date/serial]
RELENG_x   [date/serial]
HEAD/trunk [date/serial]

uname: '7.2-STABLE #0 <date of compile>' isn't quite the same solid
reference as RELENG_7 as of yesterdays code. Which is what it is,
not the zero-eth 7.2 errata/security/stability commit.

And maybe figure out a way that each commit bumps a serial counter
in UPDATING or some stampfile or uname so people can report the
serial.  Or maybe use the git crypto hash thing. FreeBSD needs a
crypto hash reference inside the primary source tree anyways, not
just on the n steps removed iso's.

I dunno, just seen year after year of these questions on the lists :)
Thought I'd put at least something out there. Not meant to be a
bikeshed or anything. More like something to be addressed by doc
project or whatever.


More information about the freebsd-stable mailing list