Thus spake Andrew Brown ("AB> ") sometime Yesterday...

AB> >> And while I'm here, I could just as well say my opinion on this: I think
AB> >> bumbing -current's version to "just_released + 1" is a good idea. So,
AB> >> we'd be now at 1.7R. And I don't think it's a problem if it is not known
AB> >> beforehand what the actual release will be called. If there won't be
AB> >> 1.7, fine. 1.7ZZZA just becomes 2.0 then (and -current 2.1A).
AB> >
AB> >Yeah, it probably would be the cleanest.
AB>
AB> so we're currently at 1.6R, which will lead to 2.0 (followed by 2.0.1,
AB> 2.0.2, etc, as needed), at which point current becomes 2.1A (followed
AB> by 2.1B and 2.1C, etc), and when we're ready, 2.2 gets branched, at
AB> which point current becomes 2.3A, etc.

This is not how I read it, which was:

2.0 gets released, -current becomes 2.1A, next release is 2.1...
2.1 gets released, -current becomes 2.2A, next release is 2.2....


This is exactly backwards from what we have now.

AB> ordering is more intuitive, odds and evens are used for development
AB> and releases, __NetBSD_Version__ can retain the same semantics it
AB> always had, and hopefully no one will upgrade (er...downgrade) to a
AB> released version from current any more.
AB>
AB> i like it.  :)

...and I don't think it was what we were looking for (seeing as there
are quite a few voices saying that they don't WANT a linuxized
versioning scheme -- you DO realise that what you said is more or less
how Linux duhs it).

A thought:

Anything with a .0 in the fourth place (i.e. null third and/or fourth
digits, 1.6, 1.6.1, 2.0, 2.0.1...) would be considered a release, while
-current would be, for 2.0, 2.0.0.1, 2.0.0.2, 2.0.0.3, etc. , and then
we release 2.0.1 or whatever, at which point -current turns into
2.0.1.[1..n].

Or Did I Miss Something, Here? [TM]


				--*greywolf;
--
Instead of asking why a piece of software is using "1970s technology",
start asking why software is ignoring 30 years of accumulated wisdom.