Subject: Re: NetBSD version naming - suggestion
To: Greywolf <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 04/24/2003 23:00:55
>>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> 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" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."