On Wed, 23 Apr 2003, 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.  :)

Oh, but I don't think that was this exact suggestion. I think this
suggestion was:

When we branch 2.0, we have 2.0, 2.0.1, 2.0.2, etc as the release branch
and 2.1A, 2.1B, etc. as current.

The next release is 2.1, and we have 2.1, 2.1.1, 2.1.2, etc as the release
branch, and 2.2A, 2.2B, etc. as current.

The idea being that -current is really the alpha of the next release.

Take care,

Bill