Overview of making Releases of the Offline Software

This describes the policy for releases of the Offline Software. This should be considered a refinement of the general description of offline software installation. For info on how to install a release see this page. For a description of the implementation of this policy by Ed, see this page.

The duties of the release manager are in green and the duties of package maintainers are in purple.

Definitions

There are two types of "releases":

Development: This constantly changing release just consists of the current state of CVS with all packages at the HEAD of their main branches. This is for people who are actively developing their own code or rely on such code.
Frozen: This consists of a branch of the main line code at some point in time. Frozen releases are created aperiodically but with a targeted average rate of once every 6-8 weeks, with particular attempt to produce one in ample time before a meeting. After being defined they should be known to work on some test sample and thereafter only bug fixes are included.
There are two types of frozen releases:
1. A point release. These are named like RX.Y.Z. There is a one to one corespondence between the name and the state of the code. Z is 0 for the initial release and increments each time bugs are fixed.
2. A generic release. These have names like RX.Y (no Z). These are installed such that it is possible to evolve them forward in time, (ie. if bug fixes are added) with out changing any of the underlying SRT directory structure.

Creating an initial (RX.Y.0) "point" Frozen Release

This describes the technical steps that package maintainers and the release manager go through to define an initial frozen release. This describes the mechanics related to CVS tags and packages files. It does not state issues about time periods, validation, etc.

These steps are to be followed in order:

Relase manager creates a "packages-RX.Y.0-tmp" file which has one line for each package stating if the most recent tag points to the HEAD of the package or not.
Package maintainers have some period to check this file and decide to specifically tag their package.
- This is optional, ignoring this step will mean that the HEAD will be used in the frozen release.
- If the package maintainer wants to explicitly tag a package, note tag should look like VXX-YY-ZZ where the numbering convention is:
  - XX (major version) changes if a very major change was made since the last tagging
  - YY (minor version) changes if any external interfaces were changed (ie, methods added/removed)
  - ZZ (bug fix or "teeny" version) changes if only bug fixes were made.
  Changing a major number implies minor numbers are set to 00. These tags are independent of any frozen release.
- Edit the packages-RX.Y.0-tmp file to add this tag on the line for the package.
After this period, the release manager does one of the following two things for each package:
1. For a package that was explicitly tagged, the generic release tag is based on the package tag:
```
cvs rtag -b -r VXX-YY-ZZ RX-Y   PackageName
```
2. For all other packages (except the special ones that are not tagged) the generic release tag is on the HEAD
```
cvs rtag -b              RX-Y   PackageName
```
The release manager then performs validation and any bugs are fixed.
After validation, the release manager makes the point release:
- ```
cvs rtag    -r RX-Y      RX-Y-0 PackageName
```
The release manager then creates the generic and point release packages files:
- The point release packages-RX.Y.0 file has each line like "Package:RX-Y-0" (or "Package:HEAD" for some special packages that always stay at HEAD).
- The generic release packages-RX.Y file has each line like "Package:RX-Y" (or "Package:HEAD" for some special packages that always stay at HEAD).

Making subsequent bug fix (RX.Y.n) "point" frozen releases

To add bug fixes to a frozen release maintainers edit the code in one of the following ways:

Check out the package to be fixed in to a "test" release based on the generic release.
Edit the code in place in a generic release.

Regardless of the method of editting the code, after the bug fixes have been made (and tested) all packages in the release are tagged by the release manager with a new RX-Y-Z tag, where Z is one more than the previous point release that was fixed. The command for this is

cvs rtag -r RX-Y RX-Y-Z PackageName

A note on CVS: committing to a point release

If you try to commit modifications to any packages in a frozen point release you can expect CVS to complain like:

bviren@minos:~> cd /home/bviren/srt/minossoft/releases/R1.0.0/PackageName
bviren@minos:PackageName> emacs File.cxx
bviren@minos:PackageName> cvs commit -m "change to point release" File.cxx
cvs server: sticky tag `R1-0-0' for file `File.cxx is not a branch
cvs [server aborted]: correct above errors first!

It is not recommended, but you can "correct" things by doing:

bviren@minos:PackageName> cvs update -r R1-0

Please be aware that doing this will change the code from a R1.0.0 point release to a R1.0 generic release but it will NOT change the underlying SRT release directory (it will stay R1.0.0). This may lead to confusion about what bugs are fixed for anyone who uses this base release for analysis.

It is better to checkout a generic release and then bug fix that.

Last Modified: $Date: 2004/02/24 17:49:04 $
Contact: minos_software_discussion@fnal.gov
Page viewed from http://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/release-overview.html


Security, Privacy, Legal