Anar here...
Since the time I moved from SVN to Git, I was looking for a convenient and automated way to build version numbers for my projects. Same as always, it appears to be very easy with Git ;)
So, coming to the subject. Every time I make a stable release, I create a tag object in git with "git tag -a vX.Y".
Now using "git describe --abbrev=4 HEAD" I can get a canonical version number, something like this: vX.Y-NN-SSSS, where: vX.Y is the latest tag, NN is a number of commits since the tag and SSSS is object's hash or just vX.Y if I would check out an exactly released tag.
The possible workflow could be the following:
- Check that project's git repo. is accessible. This is a normal case for developers builds (see #2). If it is a user who runs the build from projects's source tarball, than the repo will be inaccessible (see #3).
- If the repo is accessible, use "git describe" to get an annotated version number. Process some needed customizations of the version string (for example, change '-' to '.' and remove leading 'v'). Write the version string to a version file, which will be distributed in source tarballs.
- If the repo is inaccessible, just read the version string from the version file or use a default one.
Simple is that...
It is much easer now to maintain versioning. Every stable release, which is done after a tagging, will be named as a tag name. For example, if you have tagged v2.2, than this algorithms will return a "2.2" as a version of the project. But all nightly releases or patch releases will get additional info, like "2.2-110-gede7". Using this information you can also easily find out what exactly were changed by asking git log or git describe and giving them a version string as a parameter.
There is no need now to have 3 sections in a version string when tagging: Major.Minor.Patch. Since all patch releases will get a patch (commit) counter automatically, like: "2.2.110.ssss" and accordingly a stable release will be just "2.2".
Well I use cmake as a build system for my projects, it was therefore easer for me to implement the algorithm in the CMakeLists.txt - a build rules file. One can do the same using an external shell script or something like that.
This is what I wrote on short notice:
if( EXISTS "${CMAKE_SOURCE_DIR}/.git" )
execute_process(COMMAND git describe --abbrev=4 HEAD
COMMAND sed -e "s/-/./g"
OUTPUT_VARIABLE POD_VERSION
OUTPUT_STRIP_TRAILING_WHITESPACE)
# remove leading "v"
string(REGEX REPLACE "^v(.*)" "\\1" POD_VERSION ${POD_VERSION})
execute_process( COMMAND bash -c "echo \"${POD_VERSION}\" > ${CMAKE_SOURCE_DIR}/etc/version" )
else( EXISTS "${CMAKE_SOURCE_DIR}/.git" )
execute_process(COMMAND cat ${CMAKE_SOURCE_DIR}/etc/version
OUTPUT_VARIABLE POD_VERSION
OUTPUT_STRIP_TRAILING_WHITESPACE)
endif( EXISTS "${CMAKE_SOURCE_DIR}/.git" )This implementation returns X.Y for stable releases and X.Y.Z.SS for patch releases and nightly builds.UPDATE: By the way, I've just came across a GIT-VERSION-GEN script, which is used in the Git distributions. It does exactly this task, but a bit differently. It's very much recommend to check it out.
