Date: Wed, 8 Oct 1997 12:01:25 -0400 (EDT) From: Hetzels@aol.com To: rkw@dataplex.net Cc: stable@freebsd.org Subject: Re: CVSup release identity Message-ID: <971008120031_912347238@emout18.mail.aol.com>
next in thread | raw e-mail | index | archive | help
In a message dated 97-10-08 11:26:45 EDT, rkw@dataplex.net writes: > ># 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. Yes, I realize that they are not sub-branches. But newvers.sh refers to them as branches, and I may have used the wrong term in describing them. > > I see some value in distinguishing between releases and interim patched > versions. However, IMHO, "-CURRENT" and "-STABLE" should be dropped. I don't agree on dropping the names. Keeping the names alows users to know exactly, what they are tracking (CURRENT or STABLE). Only, "uname -v" should say CURRENT, RELEASE, or STABLE, and "uname -r" will show the release level. > 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. I would leave the mailing lists alone. Why, because as users transition from one branch to the next (2.1 -> 2.2 -> 3.0), the number of individuals to help solve problems will decrease in the older mailing lists. Plus, it forces users to unsubscribe/resubscribe to the mailing lists (for example a user upgrades to 2.2 form 2.1. He then needs to unsubscribes from the 2.1 mailing list and is forced to resubscribe to 2.2.). Besides, the same questions will be asked in multiple mailing lists, instead of just in one (stable). Also, the development team dosen't have to track 3+ mailing lists, only 2). > 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 > Scot
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?971008120031_912347238>