On Thu, 2003-04-24 at 04:55, 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.

No, I was thinking: we're currently at 1.6R. This leads to 2.0, at
which point current becomes 2.1A. At some point, 2.1 gets branched,
and current becomes 2.2A. That is: N.MX -current leads to release N.M,
and current becomes N.(M+1)X.

I realise now, though, that this would cause confusion that is the
reverse of present confusion: 2.1 would be "newer" than 2.1Z. But
on the other hand, 2.2A would be clearly newer than 2.1.1.

But perhaps this reverse situation wouldn't hurt at all, because
when 2.1 would be eventually released, -current would already be
at 2.2<whatever>. That is: people wouldn't have 2.1Z readily
available, so they wouldn't be able then to "upgrade" from 2.1
down to 2.1Z.

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