From owner-freebsd-current Mon Nov 8 15:55:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id BEECA14BFC for ; Mon, 8 Nov 1999 15:54:57 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40361>; Tue, 9 Nov 1999 10:48:59 +1100 Content-return: prohibited Date: Tue, 9 Nov 1999 10:54:46 +1100 From: Peter Jeremy Subject: Re: ambiguity between -STABLE and -RELEASE In-reply-to: <1483.942101624@cs.ucl.ac.uk> To: Theo PAGTZIS Cc: current@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov9.104859est.40361@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991108145228.C17714@stat.Duke.EDU> <1483.942101624@cs.ucl.ac.uk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-09 09:53:44 +1100, Theo PAGTZIS wrote: > If there are bugs that are resolved in >3.3-STABLE then the 3.4-RC should entail NO new functionality even if this is >supplemental. This (presumably) means that new functionality should only be introduced at major releases (eg 3.0, 4.0 etc). This is probably unacceptably slow for most people. Instead, FreeBSD takes the view that minor enhancements can be introduced with new minor releases. In some cases, the line between `minor enahncement' and `bugfix' can get blurred. >In that sense I would recommend some change in the naming (or rather >numbering) convention which in my book should be > >3.2-RELEASE -> 3.3-STABLE -> 3.3-RC -> 3.3-RELEASE -> 3.4-STABLE > >and NOT > >3.2-RELEASE -> 3.2-STABLE -> 3.3-RC -> 3.3-RELEASE -> 3.3-STABLE The only difference here is how the -STABLE branches are numbered. The 3.x-STABLE numbering does not exist in the CVS tree and is used solely as a mechanism to designate positions on the RELENG_3 branch relative to actual releases (which exist as tags in the CVS tree). For whatever reason, the decision was taken that a reference to x.y-STABLE means a location on the RELENG_x CVS branch later than RELENG_x_y_z_RELEASE. Changing that at this point in time would only cause confusion. It's also worth noting that the -STABLE branch of a release may extend beyond the last release. In particular, a couple of serious problems have been fixed on RELENG_2_2 branch since 2.2.8-RELEASE (and it's possible that future problems may lead to additional fixes on this branch), though there is no intention to ever provide a later -RELEASE off this branch. > So the RELEASE could be upgradable to the next STABLE by applying a >patch (no CVS interaction here). I trust that such patches are indeed >existing. -STABLE is not a fixed point in the CVS tree. It refers to everything between x.y-RELEASE and x.(y+1)-RC. It is fairly simple to produce a set of patches from the CVS tree to convert say 3.3-RELEASE to the `current' -STABLE ("cvs diff -u -r RELENG_3_3_0_RELEASE -r RELENG_3"), but this doesn't help someone who is running -STABLE from last month. In general, it is assumed that anyone who wants to follow -STABLE will be tracking the CVS tree. If you want bugfixes, but can't track -STABLE, you have three options: - wait for the next -RELEASE - use the -STABLE snapshots that appear from time-to-time. - find someone who can provide you with customised support. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message