Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Thu, 30 Oct 2008 07:12:23 -0700

Andrew Johnson wrote:

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.

Awesome.

Okay, this makes sense now.

This brings a slightly new question:

After a site deploys the official release point, then patches can be

obtained via another scheme.

For example, in the Known Problems area on your web site. Should there

also be a version string change?

Something like, 3.14.10-p1. Maybe, it's better for each site to handle

the version after the release point on their own since

they will most likely make some local changes.

That's why you guys created "EPICS_SITE_VERSION" ?

Thanks,
Ernest

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System