On Thu, Apr 24, 2003 at 05:55:05PM -0700, Bill Studenmund wrote:
> > 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.

Yep, luke wrote his mail while I was writing mine.

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

Actually, explicitly assumes.  It's certainly predicated on such
a decision, and I do point out that it's an assumption through the
discussion at the top.

Without getting hung up on the proposal or its assumptions, are
there any comments on the goals I set out, or any to add?  Any
scheme should be measured against *something*.

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

Agreed.

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

I thought so too until I found myself forced to respond to this
thread; near the top of my email I pointed out that we need to
decide both issues before the next branch, or we risk painting
ourselves into another corner. Otherwise, I would probably have
stayed silent.

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

Me either, but it facilitates the final proposal and does make
quite some amount of sense once you get over the newness.

In particular, for writing security advisories, it lets us say
things like "the fixes for this issue are contained in NetBSD
2.1.213" for users tracking stable by anoncvs.  Much better than
a date-based checkout of sources that doesn't get reflected in the
resulting system.

An alternative is a daily increment in something (version number
or some other value), but whatever it is needs to be reflected in
a running system to be of any great value to an end user or
administrator, especially where security advisories are concerned.

If every pullup commit includes a change to the version file, and
comment on what the new version number is, finding diffs for users
that want to patch just for the particular issue is also much easier.

[By the way, there's a separate discussion about running kernel
and userland from different sources and how to version that.  I
think it's a HUGE feature of NetBSD that we can tag the entire
source tree with a single version. People do run them out of sync,
and we could help a little more there, but they do so with some
level of risk].

--
Dan.