Software Release Structure

The software release structure provides a flexible and easy to use framework for both releasing and developing code. Code is typically grouped into packages; however, it is essential to have a release of all code in all packages. The structure must support simultaneously both releases of stable versions of the packages, and asynchronous development of the individual packages themselves. This is in contrast to a structure which is oriented solely along the lines of a release, where package versions are only stamped with the release number. The SRT software release structure, which supports both asynchronous development of packages and grouping packages into releases, is shown in Fig. 1.

The environmental variable $SRT_DIST is used as a root to add flexibility. Below it are found separate subtrees for packages and releases. Within the package subtree, each package can contain one or more different versions. This allows the package librarians to develop packages asynchronously, and assign the package a version number when the package is ready for use by others. Within the release subtree, there is a subdirectory for each existing release. A release directory consists of soft links to a set of consistent package versions, plus the libraries and binaries created from the release for various machine architectures. Again, the release manager can use this to create releases as required. Links within the release directory can be used to provide default names for particular releases, for example ``current'' for the release recommended for general use at the present time.

Notice that the soft links between releases and packages are to the source code only; the libraries and binaries are native to the release. This is necessary because in C++ a change to a header file used by package A can affect the result in package B which uses package A, even if package B does not use the part of the header file that is changed or added. In C++ if you modify a header file you have to recompile all the code that depends on that header file. The only way to insure consistent results when changing a header file is to rebuild both libraries.

Figure 1: Diagram of the directory structure. This example includes two packages: ``pkgA'' and ``pkgB''. The curved lines correspond to soft links between releases and packages.