Unique Release Number Implementation

To see if the git command is available, a find_program command was added to the CMakeLists.txt file, which sets the CMake variable PROGRAM_GIT.  An if command was also added that checks if this variable is set, which then executes the command using the  execute_process command for the describe sub-command in the project source directory setting the CMake variable ibcp_RELEASE_STRING with the resulting string.  The option OUTPUT_STRIP_TRAILING_WHITESPACE was needed to remove the trailing newline.

If the git program was not found, then the ibcp_RELEASE_STRING variable is set to "v" followed by the major and minor release numbers separated by a period.  If the patch release number is less than zero (development tag), then the patch number is appended to the release string (the dash is present because the number is negative).  Otherwise, the patch number is appended with another period separator.  The final release string, from either source, is output to the CMake output log.

In implementing this if command, it was realized that it was not necessary to test the PROGRAM_GIT variable for the string to be equal to "PROGRAM_GIT‑NOTFOUND" as was done with the awk program because this is one of the tests performed by the CMake if command.  Therefore, the if command for the awk program was simplified.

A define for ibcp_RELEASE_STRING was added to the ibcp_config.h.in file (used to auto-generate ibcp_config.h) with the contents of the CMake variable surrounded by quotes, to form a string constant that can used in the source code.  The ibcp_version() function was modified to output this string constant instead of the major, minor and patch numbers.  The "v" part of the string is not output (because "version" is already being output).  Finally, the GPL header was removed when outputting the version number to be consistent with the output of other programs.

New branch0.2 was created.  The release string produced at this latest commit will be v0.1.16b-1-g1bba2c3, which shows the most recent tag (v0.1.16b), the number of commits beyond this tag (1) and the short commit ID (1bba2c3).  The "g" in front of this ID stands for git (other letters would stand for other software configuration management systems).

[commit 1bba2c335c]

Unique Release Numbers

With a new release numbering scheme defined, there needs to be way to get the current version number into the program for output with the -v command line option (and eventually in the Help/About box once the GUI is implemented).  The version number should also be unique during development since not every commit will be tagged.  The goals are:

1. Use the current tag if at a tagged commit
2. Represent when not at a tagged commit during development
3. Use the current release number assigned for archive downloads
4. Allow for developmental (dash) and patch (period) numbering

The inclusion of the third goal will be clear shortly.  It turns out that the exact desired release string can be obtained using the git describe command, which returns the name of the most recent tag.  When beyond the most recent tag, the number of commits beyond the tag plus the short form of the current commit ID is appended.

This works as desired when the git command is available and the git repository information is present, but for the third goal, the downloaded archives have no git information.  Since the download archives are only available at tagged commits, the release number set in the CMakeLists.txt file can be used and will match the tag at that commit (assuming these variables were set to the same values as the tag).

For the last goal, there are two cases, git repository information present and not present.  When making tags during development, the tag name format will be releaseX.Y‑Z (note the dash).  The git describe command will pick this tag name (and append the rest if beyond that tagged commit).  When the git repository information is not present, the major, minor and patch release numbers set in the  CMakeLists.txt file will be used.  To handle developmental (dash) numbering, negative patch numbers will be used.

New Release Numbering Scheme

In light of the two recent problems discovered after Release 0.1.16 was made, a new release and branch numbering scheme is needed.  Technically, the third number on the release number should be for patches of a release.  Instead of using 0.1.16a and 0.1.16b, 0.1.16.1 and 0.1.16.2 could have been, but wasn't because the version numbering is currently only setup for major, minor and patch numbering, so the "a" and "b" were used (though it wasn't setup for this either).

As for branches, there is no reason to have a branch for every patch number (like with branch0.1.14, branch0.1.15 and branch0.1.16), though these were not really patches though the patch number was increasing.  Therefore, going forward there will only be branch0.2 for the developmental release 0.2 series.  As something worthwhile is completed, a tag with this number plus a dash number will be added, for example 0.2-1, 0.2-2, etc.  This will be the equivalent of the "-pre-" (and "-dev-" before that) that were used previously.

When the release series is completed, the release will be given the number 0.2.0.  (It's too early in development to worry about release candidates, but when that time comes, the "-rcX" format will be used.)  Any patches needed for a given release will then be given patch numbers 0.2.1, 0.2.2, etc.  Now to generate a unique version release number at each commit taking into account using the current tag for a tagged release...