Subject: Re: Release mechanisms (Was: "Re: Find a way for a monthly distribution")
To: Greg Earle <earle@isolar.Tujunga.CA.US>
From: Chris G. Demetriou <cgd@alpha.bostic.com>
List: current-users
Date: 07/27/1994 01:38:49
>Perhaps Chris (or someone else) could clear up something for me.  Chris talks
>about a release cycle in the above quoted text in terms that I am familiar
>with.  Declare an Alpha, code freeze it, test it out, then make changes/fixes
>and at some point, declare a beta, code freeze it, test it out, etc. all over
>again, and at some point declare an FCS (First Customer Ship) release.

For NetBSD, the release cycle is the following:
(1) "normal development" of NetBSD-current, and people running it, is
	pre-alpha.
(2) at some point, it's decided that the code should be frozen for a
	release.  At that point:
		a) the source tree is branched and tagged
		b) the tree in ~ftp starts to mirror the branch
		c) the "only" changes that go into the tree are
			"serious bug fixes."  no new features.
		d) people working on ports are encouraged to make
			binary 'snapshots' of the code at that point,
			and get them out to their users.  The last
			binary snapshot i made for the i386 is an
			example of that.
(3) as people find bugs, bug fixes go in.  more snapshots are made, as
	necessary, etc.
(4) once the system is determined to be "pretty much there", it's made
	beta.  another snapshot is made, and people start building
	"real release" binaries.  After this, the only changes that go
	into the branch are for "show-stoppers" -- i things that cause
	the system to croak in a miserable and unacceptable way, cause
	serious data loss, etc.
(5) "pre-release" binaries and installation methods are created and tested,
	and released to the users for testing.
(6) after the pre-release binaries and installation methods have been
	tested, one more set of binaries -- the final set -- is
	prepared, tested for simple things like basic installation and
	runnability (which is all that's necessary, because they're
	ideally identical to those in (5)).
(7) finally, the release is shipped.

>It hasn't been clear to me what is going on with NetBSD that parallels the
>above paradigm.

basically, we've gotten to about stage (4) now, and are in the process
of building the binary snapshots for 1.0-beta, for you to test.  It's
a relatively quiet process, because people who keep up with -current
will end up running the 'latest' beta code.  basically, it's sort-of
like there are N alpha and M beta test releases, one for each day that
the 'alpha' or 'beta' tag appears in the newvers.sh file...

There's no real announcement (nor a need for one) until it gets to be
time to teast the "pre-release" binaries, because there are people
running every day's -current, and so there _are_ people running the
code and testing it.

>I can't recall seeing an official
>"If you've sup'ped up through to today, or if you've started from scratch and
>downloaded some src tarballs and unbundled them, you've got an Official NetBSD
>1.0-Alpha system (with Secret Decoder Ring (-: )".

That's becasue we don't consider 'alpha' very much different than
normal NetBSD-current.  i do believe after i made the last binary
snapshot for the i386, i went out of my way to encourage people to use
it...

>And now all of a sudden, Chris and Adam are saying "1.0 - not Alpha, not Beta,
> [ ... ]

Not all of a sudden -- there've been a large number of hints for a
while that we were, in fact, getting into the release process...

It's not as formal as it could be, but we're not here to do formal
releases, we're here to improve the software, and make it available
in the most convenient form possible.  Releases are a side-effect,
albeit a necessary and important one, of the process of software
development and distribution.

If we were here to make money off of this, you could damn well bet
that we'd have very well-defined rules about the release process,
and very-well-announced stages.  We'd also have several people doing
nothing but release engineering all of the time, because for a
multi-architecture system like NetBSD, 'commercial quality' release
engineering could very well be a non-stop job.  Our release
engineering ins't quite 'commercial quality,' but we don't see the
most important aspects of NetBSD to be the releases themselves.


chris

------------------------------------------------------------------------------