Subject: Re: NetBSD-1.4.2_ALPHA ready for testing
To: None <xela@MIT.EDU>
From: None <Havard.Eidnes@runit.sintef.no>
Date: 12/25/1999 15:18:53
(Moved to current-users)
> I don't generally think much of "me too" messages, but as someone
> who found out about this bizarre approach to version numbering the
> hard way (and who still doesn't understand its logic), I very much
There are a couple of reasons the versioning is the way it is.
Here's a few points which tries to explain some of this:
o At the time e.g. the 1.5 release branch is created, we do not
really know for certain in advance whether the next release will
be 1.6 or 2.0. Thus, it's in some sense more convenient to
designate the development branch (past the 1.5 release branch is
created) by 1.5A, 1.5B etc.
o The letter in the development branch version designations (such
as 1.5C) has traditionally designated a particular instance of
the kernel-internal interfaces, especially those which LKMs
depend on. Note that it does not designate a user-land feature
set, e.g. the development branch version designation was not
updated when we upgraded to BIND 8.2.2-P5.
o Note that the single-letter version designations do not denote a
release, it merely marks certain points on the main development
branch, what's otherwise referred to as "NetBSD-current".
o When a release cycle is started, a separate branch in the CVS
repository is created for the release (the "release branch"), and
during the release cycle selected fixes from the main development
branch are brought in to the release branch. It is this
"separate development thread" which makes it impossible to use
the version designations along the main development branch to
compare to a release branch to find if a given feature is present
or not; while BIND 8.2.2 was pulled onto the 1.4 release branch
on the way between 1.4.1 to 1.4.2, it was not part of the
"-current" development branch until rather late, around 1.4L (?).
Also, it is the intention to use the release cycle to only add
(well-tested) bugfixes and non-intrusive changes to the system.
The intention is to improve the stability of code on the release
branch. This is the reason that 1.4.2 on i386 will still use
a.out as the object/executable format; moving to ELF would be a
far too intrusive change, and would endanger the stability of the
release branch code.
o It's worth noting that 1.4A does *not* mean "alpha test version
of 1.4". The alpha test version of 1.4 is instead traditionally
I don't know whether this adds to the confusion or whether it makes
the current version designations conventions easier to comprehend...
> Havard's paragraph above, or something very like it, should
> *always* accompany announcements of snapshots and releases, and
> appear in their README filess.
I'll try to remember it. I think we also should add some similar
text to the release notes.