EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS R3.14.10 version number
From: Andrew Johnson <[email protected]>
To: "Ernest L. Williams Jr." <[email protected]>
Cc: Core-Talk <[email protected]>
Date: Wed, 29 Oct 2008 15:39:03 -0500
Hi Ernest,

On Wednesday 29 October 2008 14:13:08 Ernest L. Williams Jr. wrote:
>
> My version string looks kind of weird:
> Cexp>coreRelease()
> ###########################################################################
> ## EPICS R3.14.11-CVS-lcls1 $$Name: R3-14-2_branch $$ $$Date: 2008/10/27
> 20:19:12 $$
> ## EPICS Base built Oct 29 2008
> ###########################################################################

The version you have checked out is not the official R3.14.10 release, it's 
something retrieved from the CVS R3-14-2_branch some time after 3.14.10.  If 
you want 3.14.10 you have to ask CVS for the tag "R3-14-10" (but then you'll 
get a sticky tag and won't be able to grab updates).

We might have changed how we handle the version numbering slightly, but IMHO 
this approach (incrementing the version number immediately after the release) 
always allows you to know when your CVS checkout occurred.  Think about this 
simplified timeline:

    3.14.9 Release

    development A

    3.14.10-RC1 Release

    development B

    3.14.10 Release

    development C


During the development periods we have the -CVS flag in the version string to 
indicate that this is not an official release point.  In development A and B 
we're obviously working on stuff for 3.14.10.  When should we increment the 
version number though?  We have to show the new version number by the time we 
do the -RC1 release, but during development B after that we still haven't 
released 3.14.10 so the version string needs to continue to reflect that we 
haven't got there yet.

The important thing is to make sure that the version number string changes 
between developments B and C to reflect that there was an official release 
between them, so we can't use the -RC1 point as the moment when we increase 
the number.  By incrementing the version number immediately after the 
release, both development phases A and B show the same -CVS version string, 
and we can use the number to distinguish between B and C.

- Andrew
-- 
Talk is cheap. Show me the code. -- Linus Torvalds

Replies:
Re: EPICS R3.14.10 version number Ernest L. Williams Jr.

Navigate by Date:
Prev: RE: EPICS build problem/question Mark Rivers
Next: Re: EPICS R3.14.10 version number Ernest L. Williams Jr.
Index: 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: EPICS build problem/question Mark Rivers
Next: Re: EPICS R3.14.10 version number Ernest L. Williams Jr.
Index: 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·