From owner-freebsd-current Sun Jul 9 19:23:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA22211 for current-outgoing; Sun, 9 Jul 1995 19:23:23 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA22199 ; Sun, 9 Jul 1995 19:23:18 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA09904; Sun, 9 Jul 1995 19:21:37 -0700 From: "Rodney W. Grimes" Message-Id: <199507100221.TAA09904@gndrsh.aac.dev.com> Subject: Re: Version numbers of the different branches? To: peter@haywire.DIALix.COM (Peter Wemm) Date: Sun, 9 Jul 1995 19:21:36 -0700 (PDT) Cc: FreeBSD-current@FreeBSD.Org (FreeBSD current), jkh@FreeBSD.Org, davidg@FreeBSD.Org In-Reply-To: from "Peter Wemm" at Jul 10, 95 07:58:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3061 Sender: current-owner@FreeBSD.Org Precedence: bulk [cc: trimmed to -current, jkh, davidg added as it will impact them on the branches and need an ack from both of them before doing this] > > On Sun, 9 Jul 1995, Rodney W. Grimes wrote: > > > > > How about making it either "2.2-BUILT-xxxxxx" or "2.X-BUILT-xxxxx" or > > > > > even "2.X-CURRENT-xxxxxx". > > > > > > > > > > > > > We should revert to something like it was before e.g. 2.2-Development. > > > > Putting the build date is not really informative because it gives > > > > no insight about the date of the files themselves... > > > > > > > > > > You can tell that the files are older than a particular date, that > > > is very useful. > > > > > > ("BUILT-950703" ? Hey, He hasn't got the "ls -s panic" patch that > > > got comitted on july 5th !) > > > > That may be true, but you surely can not say that he has all patches > > applied up to 950703 by that string, as he may have built it from > > 950301 sources... > > > > Any way I would like to have this small bit of confusing mess cleaned > > up and propose the following changes based on my understanding of ... > > Comments? > > I'd certainly vote for something like that! Thats 3 folks I have affirmation from, and no nack's so it is slated to be done some time real soon now. (Oh, joy, 3 way branch commits, hope no one is planning major work on newvers.sh :-)). Jordan, I will need your help with the make release stuff to make sure I get this right! > How about, as part of the sup scanning routines, the routine stamps in > the X.Y-DEVELOPMENT-yymmdd entrys into the freefall's > /usr/src/sys/conf/newvers.sh right before the supscan? Why don't we walk a little before we try to run. I prefer to get what I have outlined implemented and working correctly, with some testing done before we try to go to far with it. I will keep this in the back of my mind as a wizzy bang feature I should make sure I don't preclude by design. > Another different option might be to get the cron job to touch newvers.sh > immediately before the supscan, and get newvers.sh to read the timestamp > on itself while running.. I am not sure that all distribution mechanisms correctly propogate all time stamps :-(. But will keep this in mind for a future possiblility. > IMHO, the date of the source release is useful, but the build date is > potentially quite misleading. Agreed, not only ``potentially'', it has infact caused problems between people trying to diagnose a problem. > Oh, and dont forget, there's X.Y-ALPHA, -BETA and friends.. :-) Forget them I bloddy well, they are simple cvs tag's and are not branches, I don't plan to change newvers.sh every time I tag the tree. Besides 10 seconds after -ALPHA the tag needs to revert to either -DEVELOPEMENT or -STABLE. Besides only releng's can cut official ALPHA/BETA/RELEASE code so this will be handled by the ``make release SNAP= | RELEASE='' in /usr/src/release. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD