The purpose of this section is to warn users willing to use a release that is NOT the current release for their physics analyses or code development of potential problems. Within the Workbook, the use of a current release is strongly recommended, and this version of the Workbook is based on release analysis-30.

Introduction

If you are developing new code for a package, generally for adding a new feature or improving an existing one in the BaBar code, you will need to use a fairly recent release, a "production release" to make sure your code compiles against the most recent "stable" versions of the existing BaBar code.

You need to be aware that the newest versions of releases are "in production" and will not necessarily compile completely at any one time as various packages are continually being changed as developers work on improving the functions of their packages. Since the code in production releases hasn't been rigorously tested efficiencies determined for analysis, it is recommended that physics analysis be done with advertised stable releases.

Equally importantly, you should be aware that due to space limitations, releases aren't kept on disk forever. Unfortunately, sometimes the process of changing the working release could be frustrating and time-consuming.

Problems you may encounter:

when working with more recent releases than the current release, it is very likely that code will not compile properly - packages in newer releases are not guaranteed to be stable and, since they are being worked on by different developers, it is likely the packages within a release will not be compatible with each other.
when working with older releases than the current release, some code will not be compatible with newer releases of packages. Also some code may not be usable with data that has been processed with newer code releases. Also, as already mentioned, the release may be subject to deletion.

How to tell when your release is gone

Occasionally it may happen that you have stuck with the release you started using some months ago and that is it now considered "obsolete". From time to time, to free up disk space, old releases are deleted. Announcements are made in advance, through the Software Release Announcements Hypernews Forum and, if there no major objections, the releases are removed several days later. The policy on how long releases are kept is here. In general, releases with names like analysis-X are the most likely to remain for a long time, as they have been thoroughly tested and found to be stable for analyses. The other way to find out that your release has been deleted is that one day you try to compile something that worked just fine previously, and suddenly you get strange errors.

To check that it is indeed a removal of your release that is causing your programs to no longer run, you need to check the contents of the directory

  $BFDIST/releases/<your_release-number>

Sometimes the directory lives long after its contents have been removed, so the existence of the directory is not evidence enough that it has not been deleted. So don't just check that it exists - check to make sure that it is not empty.

If your release has been deleted, you will need to change your release, often updating to a newer version. At this stage it is useful to ask colleagues and look around on the BaBar web to try to find a new release that will be a) long-lived, and b) most compatible with your analysis in its current state. Changing release can frequently be very frustrating as code that has evolved may no longer be compatible with the specific code you have been using and modifying.

Available releases

All the existing releases are in $BFDIST/releases. The currently recommended release for physics analyses is (January 2006) analysis-30. The list of releases in $BFDIST/releases is:

  > ls $BFDIST/releases

10.0.1-physics-1.lst   16.0.5a                         analysis-11
10.0.3-online-1.lst    16.1.1                          analysis-12
10.1.0-physics-3.lst   16.1.1i                         analysis-12a
10.2.3-online-1.lst    16.1.1j                         analysis-12b
10.2.3.lst             16.1.3                          analysis-13
10.3.0.lst             16.1.3a                         analysis-13a
10.3.1.lst             16.1.5                          analysis-13b
10.3.1k                16.1.5b                         analysis-13c
10.4.0-physics-1.lst   16.1.5c                         analysis-13d
10.4.0-physics-1a.lst  17.1.0                          analysis-14
10.4.0-physics-1b      18.0.1a                         analysis-14a
10.4.0.lst             18.0.4                          analysis-20
10.4.1.lst             18.0.4d                         analysis-21
10.4.4-online-3        18.1.0                          analysis-22
10.4.4-physics-1b      18.1.0d                         analysis-23
10.4.4-physics-3       18.1.0e                         analysis-24
10.4.4.lst             18.1.2                          analysis-25
10.4.6                 18.1.2f                         analysis-26
12.4.0                 18.2.1                          analysis-30
12.5.2                 18.2.1b                         analysis-8
12.5.2-physics-1a      18.3.1                          current
12.6.0                 18.3.1a                         emcDev
12.6.0f                18.3.1b                         ifrDev
12.6.1                 18.3.1c                         log
14.3.2                 18.3.1d                         newest
14.3.2i                18.3.2                          nightly
14.4.3                 18.3.2a                         nightly-20060112
14.4.3g                18.3.2b                         nightly-20060113
14.4.5                 18.3.3                          nightly-20060114
14.4.6                 18.6.0                          nightly-20060115
14.4.7                 18.6.0a                         nightly-20060116
14.4.7a                18.6.0b                         nightly-20060117
14.4.7b                18.6.1                          nightly-20060118
14.5.2                 18.6.1a                         nightly-Friday
14.5.2a                18.6.1b                         nightly-Monday
14.5.2b                18.6.1c                         nightly-Saturday
14.5.2c                18.6.1d                         nightly-Sunday
14.5.2d                18.6.2                          nightly-Thursday
14.5.3                 18.6.2a                         nightly-Tuesday
14.5.4                 18.6.3                          nightly-Wednesday
14.5.5                 19.0.0                          online_use
14.5.5a                19.1.0                          simDev
16.0.2                 19.2.0                          test-SRT
16.0.2f                19.3.0                          test-SRT1
16.0.3-physics-1       19.3.1                          test-SRT2
16.0.3-physics-1a      19.4.0                          trkDev
16.0.3-physics-1b      AllEvents-Run3-OffPeak-R12.tcl
16.0.3a                ImportSun58_sparc_WS6U1

Note that not all the new releases are available, and not all should be used. A release could be present without having been built or being meant to be public, or might have been built only for a specific architecture. To know when a new release is available look in the Preliminary/unconfirmed bugs, problems, frustrations, fixes Hypernews forum for messages like the following:

This means that release 11.4.0 is ready for the public. Moreover all the problems related to this release will be posted under this announcement.

Updating individual packages, and removing individual packages

Sometimes you may wish to entirely remove an individual package that you have checked out. This is usually either because you have checked it out and then found you didn't need to change it, or the use you made of the package is now finished and you wish to use the standard build. If you remove a package your analysis job will use the library and binary files appropriate to the standard production build of that release - namely the files built at SLAC (or wherever your $BFROOT variable is pointing). To delete a single package, you can either just delete the package directory and all of its subdirectories, with

(Be VERY careful with this command!)
ana30> rm -rf package_name

(Make sure you specific the package name, as this is a powerful delete command!) Or you can use the delpkg command which also ensures that all associated library and binary get removed. The required syntax is

ana30> delpkg <package_name>

You have to answer "yes" after a few seconds to confirm removal of the package.

On the other hand, it may be the case that for your specific analysis job an expert advises you to use some packages of a different version to those that you get by default. To see the specific tagset that you have with your checked-out packages, enter

showtag

For analysis-30, with the workdir and BetaUser packages that you have checked out, you should see

BetaMiniUser V00-04-00
workdir V00-04-20

statusrel -t

The command statusrel -t gives more information than showtag, telling you the current tag for all the packages that you have checked out, the tag that comes with the release that you have, as well as the most recent version of the tag.

statusrel -tf reports differences between your tags and the same tags in CVS - i.e. it tells you any changes you might have made yourself since checking out a package, for example:

ana30> statusrel -tf
statusrel version: 1.5
Treating current directory as a test release based on 18.6.2a
BetaMiniUser  V00-04-00  (Release uses V00-04-00)    [Some files are different from V00-04-00]
workdir  V00-04-20  (Release uses V00-04-20)

The "[Some files are different from V00-04-00]" comment for BetaMiniUser is there because you altered a few files in the Quicktour and added a few also with the NTrkExample code and the update of AppUserBuildBase.cc.

To change the tags on a package you have checked out, use the cvs update command, either within the package, or in the release directory. From within the package you wish to update (or even get an older tag), enter

  cvs update -r <new_tag>

where <new_tag> will be a tag of the form shown in the showtag output above. For example, if you decided for some reason that you had to have the more recent of workdir, then the command would be "cvs update -r workdir V00-04-21". (Note that this is just an example - actually V00-04-20 is the most recent version of workdir - there isn't any V00-04-21 yet.)

In response to this command, cvs will try to update your package with the versions of programs corresponding to the new tag you have specified. Additionally, it will attempt to merge in any changes you may have made to the existing programs - so the changes you have made will not be lost!

Sometimes it happens that changes that have taken place between the different tagged versions and changes that you have made yourself occur at the same place and cvs can't merge them to its satisfaction. In this case it will report a conflict and not update the files it finds conflicts in, leaving it to you to sort out the problems yourself before the update can be completed.

From time to time new tags are prepared for "stable" releases, including the analysis-X physics analysis releases. This can be for a bug fix, or an improvement that is deemed important enough to include in a release retrospectively. The new tags listings for analysis releases are listed on the Extra Tags webpage.

You should never update a package to a tag which is more recent than the release version without a good reason (e.g. you're going to add code to the package - in which case you need the HEAD version, or you have been advised by either the Extra Tags webpage or by an expert to update), as very often code in the newer tag will not work with the other packages in an older release.

updrel - Updating a release

If you already have a release and a number of associated packages checked out and wish to update to a later release, you can use a script called updrel to update to a later release. updrel will update the checked-out packages for the tagset appropriate to your new release, merging in all the changes you have made to the existing release, and stopping and informing you of any conflicts (see above). The required syntax is:

updrel <new-release-number>

Warning: The updrel command can cause problems as it causes all checked-out packages to "update" to their release versions. The command does try to merge any changes you have made with the release version of the packages, but can cause problems, and it is generally better to just set up a new release from scratch.

A Release to use for Analyzing Real Data

To get started analyzing real data, check out the Physics Releases page to see what the currently recommended analysis release is. Release analysis-30, on which this version of the workbook is based, was the best release to use for a full analysis job at the time of writing (January 2006). In general, it is usually safe to use the most recent analysis-X release.

You should also check Hypernews forums such as Preliminary/unconfirmed bugs, problems, frustrations, fixes for information about the status of release, as occasionally even after these releases are announced as "stable", they may then found to have problems.

Back to Workbook Front Page

Authors: Massimiliano Turri
Jenny Williams
Contributors:
Joseph Perl

Last modification: 20 January 2006
Last significant update: 13 June 2005