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

what you said certainly is.  what i said was not, though it may have
been a re-interpretation of what was said.

>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).

well...besides the "that's the way linux does it" argument, it
"works".  besides, it's not *really* linuxized, since we'd still
easily be able to visually differentiate between what a release was
and what current was by the presence of the letter(s) as the suffix.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."