Some of the terminology essential to the Software Release Tools was covered above when the people involved were described. Let us now turn to other entities relevant to describing the process. You may want to keep referring back to this chapter as you read further along the manual.
Packages: A package is the smallest unit of software recognised by the release tools, and in practical terms it is defined as a subdirectory (or a subdirectory tree). For those familiar with CVS, this means that a package also corresponds to a module.
The release tools do not provide any mechanisms to deal with anything more fine grained than a package, so one has to consider a little bit what a package contains. If a package is very large, of the order of hundreds of source files, it becomes inconvenient for developers to make small modifications. On the other hand, lots of very tiny packages easily turns into a thicket of hard to manage directories, and into even harder to manage lists of libraries and their interdependencies. Typically one chooses to make some logical unit such as a domain or a class category into a package, but this is not enforced by the tools in any way.
Dependencies: Packages may and often do use other packages. For instance, code in one package may call routines in another package. Or a class in one package may inherit from a class in another package. These result in dependencies among the packages: the using package depends on the interface of the providing package. Often this also manifests as a need to link against one or more libraries from the providing package. Where the using package also produces libraries, it is often the case that for some application using both of them, one has to link the libraries in a specific order: first the using the package and then the libraries from the providing package. This obviously implies a build order as well: when a package provides a library that another package wants to link against, the library and thus the providing package must be built first.
Versions: Before proceeding to the discussion on versions, let us make a little diversion to clarify the meaning of two terms: revisions and versions. What in this manual we call a (file) revision is a snapshot of a file stored in the version management system. For instance, a file in CVS could have two consequtive revisions 1.10 and 1.11. What we call a (package) version is some snapshot of the revisions of all the files in the package, such as revisions 1.2 of PACKAGE and 1.41 of matrix.cxx, and is marked by assigning those revisions a symbolic tag such as Event-01-12-02. The terminology here, including tags, versions and revisions, is meant to be consistent with that in the CVS manual; please refer to it for the details.
Having cleared that, we observe that as packages undergo development, and as all of the changes are kept track of by CVS, it must be that each package exists in a number of versions. For SRT, we identify each such version with a triple of numbers separated by dashes, such as 01-22-35. Since the development efforts can be highly distributed and each package is relatively independent, the version numbers of one package are in general unrelated to the version numbers of other packages, even if one contains the other. Therefore, when dealing with versions, the release tools always require one to attach the package name in front of the bare numbers, resulting in version identifiers such Event-01-12-02.
These version identifiers are literally symbolic tags assigned to the package in the version management system. The release tools always require one to use the Name-nn-mm-pp style tags. Those are also the only tags the tools will see when they examine the packages. You can and should use other forms of tags for your own purposes. For instance, if you are creating a branch from version 02-04 of package Event, you might call it Event-02-04-branch.[1]
Use Dependencies: Combining the concepts of package versions and packages using each other, we notice easily that there is a coupling: as a package uses the interface of another package, it uses some particular version of it. Ideally, when package internals are changed without touching the interface, dependent packages need not know about it. In real life this rarely is so because of failures to fulfill the interface (read: bugs). Also, recently introduced interfaces often undergo heavy modification before they reach stability. Even stable interfaces are often modified by developers, if only to extend them. Many such modifications are buggy at first, and therefore break dependent packages that should not care.
In a triplet version number nn-mm-pp, nn is the major version, mm the minor version, and pp the patch level. To deal with the version dependencies in some intelligent way, we need to load some meaning on this. The release tools assume that different major numbers immediately declare the versions incompatible. If the major numbers are the same, a version with the the same or higher minor number is considered compatible. Similarly for patch levels: if the major and minor numbers are the same, the same or higher patch level will do. If the minor number is omitted, any version with the same major number will do. If the patch level is omitted, any version with the same major number and a higher or equal minor number will do.
It is clear that this numbering logic is not very fool proof. If one were to follow it literally, a young package would reach a major version of 30 in no time at all as its interface was finding the stable form. Similarly, bugs also cause havoc to the logic: a package A that otherwise is happy with a version later than 01-13 of package B may find that there is a serious bug in 01-13-02. Now what do we do? We cannot declare 01-14 the latest compatible version if other packages are not yet ready to move to it yet. On the other hand, declaring 01-13-03 as the lowest compatible version would mean that 01-14 versions could not be used when they become available. On the other hand this would also declare patch levels 00 and 01 of the 01-13 vintage unusable, even though they are fine. Worse yet, there might be a bug in 01-13-03 that is only triggered when some third package C is using A. Regardless of these deficiencies we use this scheme as it is simple and does at least a partial job. Just take it with a grain of salt.
| [1] | For a more extensive discussion on branches, please consult the CVS manual. |