------- =_aaaaaaaaaa

To: xela@MIT.EDU
cc: current-users@netbsd.org
Reply-To: current-users@netbsd.org
Subject: Re: NetBSD-1.4.2_ALPHA ready for testing 
From: Havard.Eidnes@runit.sintef.no
In-Reply-To: Your message of "Fri, 24 Dec 1999 10:03:40 -0500"
References: <199912241503.KAA28912@mint-square.mit.edu>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Sat, 25 Dec 1999 15:18:53 +0100
Sender: he@runit.sintef.no

(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
> agree.

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
   named 1.4_ALPHA.

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.

Regards,

- H=E5vard

------- =_aaaaaaaaaa--