From owner-freebsd-stable Sat Oct 4 11:07:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA28194 for stable-outgoing; Sat, 4 Oct 1997 11:07:03 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA28186 for ; Sat, 4 Oct 1997 11:07:00 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id MAA28650; Sat, 4 Oct 1997 12:06:35 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA23536; Sat, 4 Oct 1997 12:06:31 -0600 (MDT) Date: Sat, 4 Oct 1997 12:06:31 -0600 (MDT) Message-Id: <199710041806.MAA23536@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: Warner Losh , "Rodney W. Grimes" , andrsn@andrsn.stanford.edu, freebsd-stable@freebsd.org Subject: Re: CVSUP vs. SNAPS In-Reply-To: <12048.875812329@time.cdrom.com> References: <199710021509.JAA00956@harmony.village.org> <12048.875812329@time.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 2.2 is the branch ID [ Arguements about what CVS does ] That's *irrelevant* to what goes out the door. Just because the release engineering process uses a TAG of 'foo', doesn't mean that a release can't be called 'bar'. I'm with Rod on this one. With the 3.0 release, I think we should call the original release '3.0.0' if we plan on having multiple releases. How CVS fits in this is really irrelevant, since the users don't care for the most part how it's done, and CVS will support whatever we want it to do. There is a *huge* different from a 2.2-stable box that was built slightl after '2.2-RELEASE', and one built today. It would be nice (and trivial to do) to have the branch tag change *AFTER* 2.2.5 to say '2.2.5-stable'. But, it doesn't have to happen until *after* the bits are set down for 2.2.5, so arguments now are only wasting time. We can always argue for it after 2.2.5 is done. :) :) Nate ps. I note that the 'tag' used to denote '2.2-RELEASE' is "RELENG_2_2_0_RELEASE" and *NOT* "RELENG_2_2_RELEASE", which is what Jordan is arguing about. Even internally the tags seem to support what Rod and others are arguing for, we just want to make that information available to the kernel.