Subject: Re: NetBSD version naming - suggestion
To: Andrew Brown <firstname.lastname@example.org>
From: David Maxwell <email@example.com>
Date: 04/23/2003 23:26:45
On Wed, Apr 23, 2003 at 09:55:00PM -0400, Andrew Brown wrote:
> >> And while I'm here, I could just as well say my opinion on this: I think
> >> bumbing -current's version to "just_released + 1" is a good idea. So,
> >> we'd be now at 1.7R. And I don't think it's a problem if it is not known
> >> beforehand what the actual release will be called. If there won't be
> >> 1.7, fine. 1.7ZZZA just becomes 2.0 then (and -current 2.1A).
> >Yeah, it probably would be the cleanest.
> so we're currently at 1.6R, which will lead to 2.0 (followed by 2.0.1,
> 2.0.2, etc, as needed), at which point current becomes 2.1A (followed
> by 2.1B and 2.1C, etc), and when we're ready, 2.2 gets branched, at
> which point current becomes 2.3A, etc.
> ordering is more intuitive, odds and evens are used for development
> and releases, __NetBSD_Version__ can retain the same semantics it
> always had, and hopefully no one will upgrade (er...downgrade) to a
> released version from current any more.
> i like it. :)
I mostly like it. I can see some confusion on the part of users though.
There's a 2.0 release, and a 2.2 release... what happened to 2.1 ?
Alternately, release 2.0, call -current 2.0.9A[B-Z], and the next
release is 2.1
The only constraint imposed by this is that we can never have 9 patch
releases. I doubt that causes a problem.
David Maxwell, firstname.lastname@example.orgemail@example.com -->
(About an Amiga rendering landscapes) It's not thinking, it's being artistic!
- Jamie Woods