On Fri, 25 Apr 2003, Daniel Carosone wrote:

> [I'm going to hate myself for chiming in here...]
>
> We (seem to) have decided that the next release series (including
> patch rev's) will be 2.x - ie, we drop the third digit.  I am glad
> to hear this, I've been advocating this position for some time.

Uhm, it hasn't been decided. It was floated, and Luke and JD picked up on
it, but it's not decided yet. One of Luke's more recent EMails reitterates
this.

The fact the next release is 2.0 _has_ been decided, but that more stems
from the fact that for most of the project's history we've said we'll do
2.0 when we have SMP & pthreads. We have that, thus 2.0.

We're muddling a few things here. There's how do we name current so it's
not confused with releases, and what should the release after 2.0 be.

We're chatting quite a lot about how to name current, and I think most
folks agree something different would be good. We don't have concensus,
but I figure this is something core'll just have to decide.

We haven't however discussed what the release after 2.0 is. I still like
2.1, but that's a separate discussion.

The rest of your EMail implicitly assumes that the release after 2.0 is
3.0, so I'm not sure what to say since that's not a given.

> The people proposing version schemes with *four* dot-separated
> parts illustrate exactly why I dislike the three-part ones; too
> complex.  We just don't make enough releases to need the numbers.
>
> In this scheme, as previously discussed, releases go
>  2.0, 2.1, 2.2 for releases off the next branch.
>  3.0, 3.1, 3.2 for releases off the branch after, that include new
>                stuff from -current beyond the normal pullups.
>
> What hasn't been discussed (up to now) is how to name -current
> under such a scheme.  I like the present scheme, but the choice
> (assumed) above requires a change to this too, it breaks the pattern:
>
>  * I think we all assumed it would be 2.0A after the branch is created
>    - but hadn't quite noticed that after the 2.1 patch release comes
>    out, -current would still be 2.0R or whatever.. I think this creates
>    a different kind of problem, it seems to imply that 2.1 contains
>    more stuff from development in -current than it does. This is
>    *worse* than the present confusion over whether 1.6.1 has stuff
>    from 1.6R in it.
>
>  * If we were to follow the pattern we have now, but shift the digit
>    as well, -current becomes 2A. I'm not sure I like that, nor that
>    many others would.
>
> However, I don't really like any of the proposed schemes in this
> thread.  Before I propose another, I'd like to list some features
> I think we want (and that each of the proposed schemes lacks
> somehow).
>
>  - as simple and obvious as possible (no minor-minor-minor version
>    numbers unless we're really changing them every week)
>
>  - something that shows the clear differences in kind between bumps
>    of -current and bumps of the release branch (not just odd/even
>    numbers). These changes reflect different kinds of work.
>
>  - something that shows the clear difference between the releases
>    (off whatever branch) and -current.
>
>  - something that helps users understand the lineage and branching
>    structure, so they know what they're getting.  This is especially
>    important if we ever get so good at doing releases that we have
>    intermingled (in time) releases off several branches.
>
>  - something that avoids the "subtractive" version number problem, where
>    1.7X < 1.7, or to a lesser extent, 1.7_BETA < 1.7 (I think users
>    are comfortable/clear enough on the latter).
>
>  - something that lets developmental versions (current and along
>    the branches) be identified.
>
> So, I propose:
>
>  - Each release series takes a major number (2.x 3.x)
>
>  - Minor number (2.0, 2.1, 2.2) represents the amount of release
>    engineering effort.
>
>  - Therefore, the first tested release is n.1 (2.1), *not* n.0.
>
>  - n.0 represents -current up to the branch that leads to n.1, n.2, ..
>
>  - -current continues to use a letter to indicate both incremental
>    API/ABI changes, as well as its different nature.  This would
>    be as now - 2.0A, 2.0B - or just possibly 2.0.A, 2.0.B, ...
>
>  - when we branch, current becomes 3.0A (3.0.A)
>
>  - releng gets to make the call on what to name incremental points
>    leading up to actual formal releases: the 2.1_RC1 style names.
>    I'm perfectly happy with _RC or _PRE.
>
>  - Likewise _STABLE between minor releases.  While it might be
>    tempting to use 2.1.1 or even 2.1.A for -stable points, doing so
>    risks confusion with -current and with our present scheme.
>    If a minor-minor number is used here, I'd like to see it serially
>    increment with each pullup, so it's *clearly* different to
>    present usage.

Well, that's different. I'm not sure if I like it or not.

> This scheme *doesn't* match what developers and cvs users see as
> the branch point like our present one does - we have version numbers
> of 2.0X before there's a netbsd-2-0 branch. That's a shame, but
> since we seem to be so worried about confusing the newbies rather
> than the experienced developers, we need to favour them and expect
> developers to understand the difference. The branch tag itself
> would probably be better called "netbsd-2", in this scheme.
>
> This does much better match what end users see as the final polished
> result of our development efforts in -current and releng efforts
> along the branch.
>
> Taking it further (and perhaps too far?)
>
>  - 2.A, 2.B for current leading up the the 2.x branch
>
>  - 2.0 for the branch point (when current becomes 3.A)
>
>  - 2.0.nnn for the nnn'th pullup on the 2.x branch prior to 2.1
>
>  - 2.1 for the first release
>
>  - 2.1.nnn for each pullup thereafter
>
> Perhaps the key point about this scheme is it only took 5 lines to explain.

I'd say perhaps too far. :-)

Take care,

Bill