From owner-freebsd-hackers  Fri Apr 21 00:34:57 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id AAA02457
          for hackers-outgoing; Fri, 21 Apr 1995 00:34:57 -0700
Received: from localhost (localhost [127.0.0.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA02449
          ; Fri, 21 Apr 1995 00:34:55 -0700
X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol
To: Mark Hittinger <bugs@ns1.win.net>
cc: hackers@FreeBSD.org
Subject: Re: Release stability (fwd) 
In-reply-to: Your message of "Thu, 20 Apr 95 15:32:02 EDT."
             <199504201932.PAA04694@ns1.win.net> 
Date: Fri, 21 Apr 1995 00:34:55 -0700
Message-ID: <2448.798449695@freefall.cdrom.com>
From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> In the old DEC world there was a three piece cycle that was followed
> many times.  A feature release followed by a robustness release.  There
> was also a performance release that followed the robustness release.
> 
> The focus was shifted during each release to concentrate on the 
> primary goal of that release.  Customers knew what to expect in
> general terms.
>
> We seem to be trying to do all three simultaneously and I don't think
> its really possible to do.

This is about the best general summary of the situation I've seen yet.

Yes, I think that a new/stable/fast cycle of 3 has a lot to be said
for it.  What would people say to us going to the following numbering
scheme in support of this?

<rel>.<0,1,2[,3..]>[.<snap>]

Where a bump in <rel> would signal a fairly major paradigm shift of
some sort, the 0 release for which would be the "features" release.
It wouldn't be guaranteed not to eat you and your entire family for
breakfast, it would be for the rocket jockeys who enjoy riding out on
the bleeding edge.  The .1 release would be the fixed version of the
.0 and for the more staid sorts.  The .2 release would be the final
stage of evolution with things sped up and generally made to work
"optimally", for whatever the value of optimum might be.

If we needed snapshots, those would trail between in the "100's place"
with things like 2.0.1 or 2.1.2 being valid and reasonable snapshot
names (the 1st post-2.0 snapshot and 2nd post-2.1 snapshots,
respectively).

This would also remove Garrett's objection to date-based snapshot
names.  I could be more than happy with a release numbering scheme
(and underlying philosophy) like this.  What say the rest of you?

						Jordan