Besides build and TPC management, version management constitutes the third major area of ComPact's functionality. This chapter contains all what needs to be said about that, assuming basic knowledge of version control according to the check-in/check-out model. In the latter scheme, as seen from the ComPact perspective, a repository is used for recording package versions, that is, package states efficiently. To gain access to some version, the PkgDesc and all its source files are checked out from the repository; to record a new state as a version, these files are checked in. The repository is located centrally, so that all versions ever recorded are accessible to all developers. Furthermore, developers check out package versions to their local work spaces, and check in new versions of these packages in the course of further development. This combination of a central repository and local package changes and updates is the essential basis of check-in/check-out version management on a global scale.
The section called The General Development Model introduces the development model that underlies version management with ComPact, Section 7.2 is concerned with some general technicalities, Section 7.3 is concerned with recalling how to create new package collections and packages, retrieving package versions from the repository, and merging different versions and Section 7.5 describes how to check in a package in your working directory as a new development or release version. Section 7.6 describes how to examine the version history of a package and last but not least Section 7.7 describes how to ship versioned package installations, and how to import them into other packages.
On a preliminary remark, ComPact relies on an external version control system for realizing all of this functionality. CVS is currently the only such system it is able to work with. Future releases will support additional systems. Independently of that, the command suite provided by ComPact should suffice for most users. In other words, you should hardly ever feel any necessity for working directly with CVS or whatever.
Commands that Operate on Entire Packages: Considering the version management front end, most commands operate on entire packages. This feature is an obvious advantage wrt. using the underlying or any other version control system, for that matter. The reason is that conventional systems, because of their generality, must operate on files.
It is widely accepted that prudent software engineering practice strongly discourages recording versions in an ad hoc fashion. Rather, one must focus on their succession, using some general scheme to organize it, and, at the same time, make it transparent. A popular basis of that consists of employing a hierarchy of version numbers such as major numbers, minor numbers, and patch levels. Indeed, ComPact adopts this approach: On the command level, each compound version number is of the form
[d]<major_number>_<minor_number>_<patch_level>The qualifier d designates a development version.
The ComPact development model, then, is exemplified by the diagram below. First, there is a so-called main trunk, which is made up of the development versions of some particular package in linear order (vertical branch); second, there are zero or more release branches, which are respectively made up of a sequence of package versions, where each change to the package is a patch (horizontal branches). These branches are, therefore, characterized by the fact that all of their members have the same major-minor number. Their heads may be designated by version numbers of the form
<major_number>_<minor_number>_stable
Part of the pragmatics is, of course, such that development takes place on the main trunk. Moreover, we have already indicated that releases are understood to be stable except for patches. In other words, a new branch should be created whenever the corresponding release involves more than a patch with regard to prior ones.
d0_0_0
V
d0_0_1
V
d0_0_2
V
d0_1_0
V
d0_1_1
V
d0_2_0
V
d0_2_1 -> 0_1_0 -> 0_1_1 -> 0_1_2 = 0_1_stable
V
d0_3_0
V
d0_3_1
V
d0_3_2
V
d0_3_3 -> 1_0_0 -> 1_0_1 -> 1_0_2 = 1_0_stable
Note: Releases may be shipped on a project-wide or gobal scale.
Also, there is a guideline with regard to what should be considered a release: A release is a package version whose installation you would ship to a project or global pool. In accordance with that, ComPact discourages any shipment of some development installation to a location that is not a local pool.
As for version-based package imports, there may be references to specific versions or to version ranges. Then the newest version is selected. In particular, it is possible to import the installation of the current head of some release branch regardless of what patch number it actually has. This feature testifies very nicely for the high degree of integration of version and build management exhibited by ComPact. In the same vein, there is a multitude of consistency checks that refer to both of these areas of functionality. One of the most important ones consists of ensuring that no release version imports any development installation.
To finish this section, the general development model may be put into a wider perspective as follows:
Every sub-system embodied by a package is treated like a project on its own.
The model is simple yet powerful enough for keeping these individual projects under control, since
there is a single development effort, which is represented by the main trunk, in combination with
a succession of releases, which are stable except for patches or, in other words, bug fixes.