Subject: Re: Release cycles (Was: Re: RealAudio)
To: The Grey Wolf <>
From: Bill Studenmund <>
List: current-users
Date: 11/03/1997 15:11:00
On Mon, 3 Nov 1997, The Grey Wolf wrote:

> This may sound kind of wacky, but how about the concept that between
> releases M.m and M.(m+1), the "interim releases", i.e. M.m.X, the X
> doesn't have to be all inclusive or sequential.

[details snipped]

> Whadaya think...?

I'd have to agree with the other comment that it'd be a release
engineering nightmare. Basically you've described each ports' snapshot
system. Though I think it's useful, I don't think it should be made
"official" (given release #'s).

But I do think we need to do something about the problem you're trying to
address; we seem to hate releases. I'd like to suggest we do something
about the release system.

Note: everything I've seen about 1.3 seems good. I'm not complaining about
it. I'm more concerned that we don't wait another 18 months for 1.4.

Right now, we seem to go along outside of release mode, then drop into
release mode and say, "Shit. We have to do a lot of work!" My ideas are to
kinda keep us in release mode, so that the work backlog never gets too big
(or at least stays a little smaller :-)

My two suggestions:

1) Let's start on 1.3.1 as soon as 1.3 is done (assuming we're not going
directly to 1.4). Since 1.3.1 is just a bunch of bug fixes, as developpers
fix bugs (not add major new features), let's commit them to 1.3.1.

If some of the release engineers don't really want to stay on for 1.3.1,
maybe we draft replacements. I'd volinteer but I don't think I'm
knoledgable enough about everything (some things yes, just not
EVERYTHING) to do more than pull up changes.

2) What would it take for us to develop a NetBSD-stable, a la FreeBSD? I
know it will take disk space both on and
Also, it will mean more work for (since some folks will
want to sup -stable). It also will take effort on the part of developpers
to actually put stuff in it.

My suggestion would be either to do whatever FreeBSD does (at least study
them), or ask developpers to commit their changes to it after they've been
tested in -current for a while.

Something like merging in changes to -stable about a month (or two weeks)
after adding it to -current. Just rip the diffs out of cvs & put them on
the -stable branch.


Take care,