From owner-freebsd-stable  Wed Oct  8 08:26:48 1997
Return-Path: <owner-freebsd-stable>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA23840
          for stable-outgoing; Wed, 8 Oct 1997 08:26:48 -0700 (PDT)
          (envelope-from owner-freebsd-stable)
Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA23832
          for <stable@FreeBSD.ORG>; Wed, 8 Oct 1997 08:26:45 -0700 (PDT)
          (envelope-from rkw@dataplex.net)
Received: from [204.69.236.50] (GATEWAY.SKIPSTONE.COM [198.214.10.129])
	by shrimp.dataplex.net (8.8.5/8.8.5) with ESMTP id KAA01460;
	Wed, 8 Oct 1997 10:26:39 -0500 (CDT)
X-Sender: rkw@mail.dataplex.net
Message-Id: <l03110700b061515db67d@[204.69.236.50]>
In-Reply-To: <01bcd3f4$a0e6ea20$LocalHost@hetzels>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 8 Oct 1997 10:26:38 -0500
To: "Scot W. Hetzel" <hetzels@aol.com>
From: Richard Wackerbarth <rkw@dataplex.net>
Subject: Re: Fwd: CVSup release identity
Cc: stable@FreeBSD.ORG
Sender: owner-freebsd-stable@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

># uname -r
>
>2.2.2 (199710081259)
>
># uname -v
>
>FreeBSD 2.2-STABLE ...
>
>According to the man page "uname -r" gives the Release Level, while
>"uname -v" shows the version, along with other information.  "uname -v"
>could also indicate the development branch (CURRENT, RELEASE, or STABLE) for
>the source.

Please realize that "CURRENT", "RELEASE", and "STABLE" are NOT different
sub-branches. The branches are 2.1, 2.2, 3.0, etc.

Each "-RELEASE" indicates a particular waypoint on its branch.
"-CURRENT" and "-STABLE" are just a description of the intended status.

I see some value in distinguishing between releases and interim patched
versions. However, IMHO, "-CURRENT" and "-STABLE" should be dropped.
All references to a particular branch need to be in terms of its invariant
name, eg "2.2". Further, I would phase out the "stable" and "current"
mailing lists in favor of lists designated by the particular branch's
numeric name.
That way, the purpose of a list would not need to change as development
progresses. The transition can be handled by cloning existing mailing lists
and using mail aliases to allow the deprecated names to continue to
function as expected.

Richard Wackerbarth