At Fri, 25 Apr 2003 00:40:19 +0000 (UTC), "Daniel Carosone" wrote:
> [I'm going to hate myself for chiming in here...]

likewise.

I've become a fan of the gnu-ish "ninety-something" version numbering,
for development-trunk versions, e.g.:

	2.0	major
		2.0.90	branch development before release
		2.1	patch release
		2.1.90	branch development before release
		2.2	patch release

	2.90.0	development before next major.
	2.90.1	development before next major, after abi change.
	2.90.2	...

(in the latter, a number takes the place of the letter.  it could stay
a letter, but, well, the letter means a number, and there are always
questions about what to do after Z.  8-)

and if for some reason something *really* major happens on the trunk
or branches, one could use 91, 92, etc.  8-)

This is easily representable ins __NetBSD_Version__, and i think it
fairly obviously represents the relationship between various versions
in an easy-as-possible way to understand.  (There *is* no well-defined
relationship between 2.1 and 2.90.*, other than 2.1 contains some
small fraction of the changes in 2.90.*, so you can't easily explain
it.)

(I'd also add a nightly-incremented datestamp #define, btw.)


> So, I propose:
> [ ... ]

I'm not so keen on this because:

(1) we're going to still get lots of questions about this letters and
numbers thing.

(2) using "M.0" as the a "development trunk" version number seems
... non-intuitive, and not generally excepted practice among other
open-source or even closed-source software development groups.  I
think it would cause continued confusion.


cgd