When a particular build of an Athena project is deemed ready for production it will be installed as a numbered release onto the ATLAS production CVMFS server.
ATLAS software is numbered according to the following scheme:
A.B.X[.Y]
A refers to the release series, e.g., release series
21 is being used for Run 2 simulation and data taking in 2017
and 2018.
B is the release flavour and usually corresponds to a particular
branch in the git repository for which the code base needs to be
different. e.g., 21.0 is the release for MC16 simulation
(and Tier-0 reconstruction), but 21.3 is used as a development branch
with MC18 code changes in it; 20.1
contains the extra-stable variant of the code for online data taking.
Principle release flavours are:
| Flavour | Purpose |
| 0 | Tier-0 reconstruction and corresponding simulation production |
| 1 | High Level Trigger online data taking |
| 2 | Derivations and Analysis |
| 3 | Simulation development |
| 5 | The union of .0 and .1, Tier-0 but with most recent trigger changes (also known as TrigMC) |
| 9 | Upgrade studies |
Note that there is a strong correspondence between release flavour and
Athena Project, However, it is not
absolute, e.g., AthDerivation and AthAnalysisBase would
both be built from flavour 2.
X is the major release number, monotonically increasing as code is developed
with bugs fixed and enhancements added.
Y is used is a minor release number is required for developments
that branched from an older major release. e.g., 21.0.20.Y contains
any fixes required for MC16a, as releases 21.0.21 onwards contained
incompatible changes for MC16c.
If needed additional sub-minor release numbers can be added, but this would be a rare occurrence.
To setup a production release the release number and project need to
be specified to asetup, e.g.,
asetup Athena,21.0.23
It is very easy to see which production releases are available, just by looking in CVMFS, e.g.,
$ ls /cvmfs/atlas.cern.ch/repo/sw/software/21.1/AthenaP1/
21.1.0 21.1.1
Where the release series and flavour are encoded in the highest
level directory, then the project, then the release number
(/cvmfs/atlas.cern.ch/repo/sw/software/A.B/PROJECT/RELEASE_NUMBER).
See the full asetup users guide for further options.
When a git tag is made for a production release the release coordinator will add some release notes to the tag, which you can read directly in GitLab (just navigate to the tag of interest) or through the git command line:
$ git show release/21.0.23
tag release/21.0.23
Tagger: Hass AbouZeid <hass.abouzeid@cern.ch>
Date: Fri May 12 10:17:36 2017 +0000
Release used to reconstruct LHC commisioning data, and cosmics
(combined muon rec turned off) at the Tier0. This release does
*not* conserve FT0 policy with respect to 21.0.22
commit a55926e1404de0dc997ac370b53a0c3a3b1cff8d
...
If you need to find out which nightly build
corresponded to a particular release the ReleaseData file contains
useful information:
$ cat /cvmfs/atlas.cern.ch/repo/sw/software/21.0/Athena/21.0.23/InstallArea/x86_64-slc6-gcc62-opt/ReleaseData
[release_metadata]
release:21.0.23
nightly name:21.0
project name:Athena
nightly release:a55926e140
date:2017-05-11T2150
compiler:GNU-6.2.0
You can also search for references with the right tag or hash
in git using git describe:
$ git describe --tags --match 'release/*' nightly/21.0/2017-05-11T2125
release/21.0.23
$ git describe --tags --match 'nightly/*' release/21.0.23
nightly/21.0/2017-05-11T2125
$ git describe --tags --match 'nightly/*' a55926e140
nightly/21.0/2017-05-11T2125