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
For a description of the implementation of this policy by Ed, see
The duties of the release manager are in
green and the duties of package
maintainers are in purple.
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
- 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.
- 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
- If the package maintainer wants
to explicitly tag a
package, note tag should look like
VXX-YY-ZZ where the numbering
Changing a major number implies minor numbers are set to
00. These tags are independent of any frozen release.
- 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.
- 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:
- 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
- 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:
- 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:
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
- 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.
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
Last Modified: $Date: 2004/02/24 17:49:04 $
Page viewed from