From owner-freebsd-stable Tue Oct 7 20:21:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA14033 for stable-outgoing; Tue, 7 Oct 1997 20:21:39 -0700 (PDT) (envelope-from owner-freebsd-stable) Received: from bob.tri-lakes.net ([207.3.81.6]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA14027 for ; Tue, 7 Oct 1997 20:21:30 -0700 (PDT) (envelope-from cdillon@tri-lakes.net) Received: from [207.3.81.130] by bob.tri-lakes.net (NTMail 3.02.13) with ESMTP id sa292960 for ; Tue, 7 Oct 1997 22:21:34 -0500 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199710071655.JAA07589@freebie.dcfinc.com> Date: Tue, 07 Oct 1997 22:05:13 -0000 (GMT) From: Chris Dillon To: chad@dcfinc.com Subject: Re: Fwd: CVSup release identity Cc: stable@FreeBSD.ORG Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 07-Oct-97 Chad R. Larson wrote: >> On 07-Oct-97 Richard Wackerbarth wrote: >> >Chris Dillon writes: Actually, Richard Wackerbarth wrote the following, not me. >> >I guess we could do the following: >> > >> >Before release: >> >2.2 (9710061501) >> > >> >At release: >> >2.2.0 (RELEASE) >> > >> >After release: >> >2.2.0 (9710061703) >> > >> >Another Release: >> >2.2.2 (RELEASE) >> > >> >And then: >> >2.2.2 (9710061905) >> > >> >That way, anything other than a release would have a timestamp and the >> >number of the previous release from which it was derived. > >As someone pointed out, this still doesn't make clear the distinction of >a >SUP against 2.2-CURRENT and 2.2-STABLE (something my earlier suggestion >also failed to do). 2.2-CURRENT? Thats a new branch to me... Unless you are speaking hypothetically of a branch which has not yet had its first release, which in that case, is still taken into account by the above example. >I'll re-suggest an alpha-numeric counter instead of date/time, both for >economy (fewer characters) and to avoid debate about time zones and >daylight savings. But I'd add a character that denotes which CVS tag >was used to retrieve the sources. Obvious characters would be 'C' (for >current), 'R' (for release) and 'S' (for stable). The other 23 >characters could (and should) be assigned to any other tags accessable >to non-core team members. What better alphanumeric incremented counter than time itself? Sure, its a few more numbers, but it is constantly being incremented, is pretty fine-grained, and much more informational. And time-zones aren't a problem when its the server supplying the timestamp, not the client. >So, we'd see something like this: > >2.2-CAB >2.2-SCD >2.2.5-R > > -crl It'd work, but... think of all the nasty letter combinations that will crop up. :-) Not to mention that the letter-combinations will be eventually recycled, possibly causing more confusion. It would take a century for the current two-digit-year timestamps to recycle. Make it a standard four-digit year and we won't have to worry about changing it again until the year 10000. :-) --- Chris Dillon --- cdillon@tri-lakes.net --- Powered by FreeBSD, the best free OS on the planet ---- (http://www.freebsd.org)