7.5. Committing and Releasing New Package Versions

You should use -commit or -release once your current work package needs to be recorded:

[ <commit_option> ] ( -commit | -ci ) ( major | minor | patch )
[ <commit_option> ] ( -release | -rel ) ( major | minor | patch )

the option being

( -msg | -m ) <log_message> | ( -file | -f ) <file_name>

As a precondition of -commit, the package tag must refer to the head of the main trunk. -- In other words, the main trunk cannot grow from within. -- The number of the newly created version will be generated by increasing the number of the current version as specified by the major/minor/patch argument.

Turning to -release, there is no precondition, that is, branches may grow everywhere. Whether there will really be any new branch, however, depends on the major/minor/patch argument and the current tag. In case of a patch level increase and a tag that refers to the head of some release branch, that branch will be extended; in case of a major-number or minor-number increase, a new branch will be created regardless of the tag. The new version number will be based on the latest release number up until then and, at the same time, on whether a major-number or minor-number increase is desired.

In each case, the current work package will be re-tagged according to the new version number. Another common aspect is the possibility of supplying a log message on the command line -- ( -msg | -m ) <log_message> -- or by means of a file -- ( -file | -f ) <file_name>. If you omit either of them, then ComPact will ask you for a message by invoking an editor. It is recommended to choose the log message well and make it as concise and informative as possible.

The actual commit or release of changes may depend upon the execution of an external program specified by the values of the configuration variables external-package-commit-hook, external-package-release-hook, and external-commit-hook. Commit and release hooks are used to connect Elego ComPact version management facilities to external problem report or request tracking systems. The general procedure is as follows: an external command is invoked with the log message, a request identity extracted from it, or other similar parameters. The check program may inspect the syntax of the log message as well as query a database containing problem reports or change requests in order to validate or invalidate the intended commit. A common precondition for the commit of changes is the existence of an open problem report or request to which the changes refer. See Section External Commit Hooks in the Project Manager Manual for further details.

If you release a ComPact package, several more preconditions are checked before a release can be made:

1. The package description file must have been parsed without errors.

2. All imports must resolve without conflicts.

3. The package must have been built successfully.

4. No non-release versions of packages must be imported.

5. All files known to be needed according to the package description must be under version control.

A package is recognized as a ComPact package if its package kind name contains the string compact (case insignificant).

Finally, you may check in package versions with arbitrary tags by means of

[ -branch | -b ] -tag <your_tag>

This feature is useful if you have your own tagging scheme. Yet, ComPact does not provide any further support of that.