Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Jul 1995 19:21:36 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
To:        peter@haywire.DIALix.COM (Peter Wemm)
Cc:        FreeBSD-current@FreeBSD.Org (FreeBSD current), jkh@FreeBSD.Org, davidg@FreeBSD.Org
Subject:   Re: Version numbers of the different branches?
Message-ID:  <199507100221.TAA09904@gndrsh.aac.dev.com>
In-Reply-To: <Pine.SV4.3.91.950710074134.8698B-100000@haywire.DIALix.COM> from "Peter Wemm" at Jul 10, 95 07:58:28 am

next in thread | previous in thread | raw e-mail | index | archive | help
[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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507100221.TAA09904>