To transfer projects to external users, a release can be created. Instead of a binary release VMake supports source code level releases. VMake distinguishes major, minor and patch releases.
For a patch release the release information is compared to the current project save information to find all new, changed, and removed (obsolete) files. The changes are stored in a patch data file. During the patch the local release information file and the release source tree are updated. Files which have been accidently removed from the release source tree are copied again to the release, but no data is put into the patch data file. If no differences are found the empty patch data file is removed. So in addition to the patch file, a full patched release tree is generated for archiving or shipping. The release information file is updated to reflect the new status of the files. The patch data file is much smaller than a full release because only differences are transfered to the customer's platform.
The generated patch data can be applied by VMake to update a release at the customer's platform by using the update option applyPatch. VMake checks for conflicts during the update procedure (see Section 7.3.2).
The full design loop from local development up to a release is shown in Fig. 6.19. The central point of the development is the common code repository. Every night the projects are tested by an automated selftest. VMake builds all files and executes the selftest goals. In the global development loop incompatible changes in the sources done by between different engineers are so detected. The global design loop is also called integration test in [Bro82]. Errors reported by the automatic test should be corrected as soon as possible because they influence the work of other developers.
Abbildung 6.19: Software development cycles with VMake
If a so called ``tagged'' release is generated, the version numbers in the Project-Definition (see Project-Definition) are automatically updated to the next version, either major, minor or patch level. The release is then marked symbolically in the common code repository. This symbolic marker can be used later for reconstruction of the released or patched project. This is important if a bug is reported by an user for a specific version of a project.
To create a binary release of a project, an installation of the project has to be done. The installation tree can be shipped directly to the end user. Problems may arise with shared libraries if the binary version is installed in a different location than the original installation. In this case the operating system environment variable LD_LIBRARY_PATH can be used to solve the problem. This variable must be set to point to the directory with the shared libraries. In contrast, an archive binary release version of a project is much larger than a shared version due to the fact that the code of the libraries is included in every executable.