I've written a command line tool and I want it to print out the current version of the program if I type in the --version command. I've got a git repository setup for my program so I figured maybe I could somehow hook into that to get version information from tags or something?

What happens when I type in program --version into my terminal? Presuming I have some kind of flag parser setup where I can check that the version flag is present, how do I handle this?

The only way I can think of doing this right now is with a simple hard-coded value e.g. #define VERSION "0.0.1", but I'm sure we can do better than that, right?

  • 7
    The hard coded value is essentially the way it's done in the executable, for the most part. – whatsisname Dec 6 '16 at 2:25

Basically, the version string needs to be embedded somewhere in the program.

The interesting part is how to make it easy to keep this version in sync with other places where you might want to have the version number, such as your version control, documentation, build configuration files, etc. Such a mechanism can reduce the amount of work and prevent mistakes such as updating the version in one place but not in the other.

You could, for example use tags in your version control as the main source of information and propagate this information to the other places. You could write a custom script/makefile for this purpose and read the version from "main source of truth", then propagate it into other places via command-line parameters, generating resource files with the appropriate definitions or replacing template parameters such as $VERSION in some files, etc.

You could also try to use a ready-made piece of software - availability may depend on what you use to build your software. For example, if you are using Gradle, axion release plugin embraces this approach and propagates the version found in git tags to JAR names and metadata which the application can then read and display when asked to.


This often comes out of the build mechanism. e.g. you make a decision that your next release is version 1.x. That gets embedded in a config that is then referenced or statically embedded within your source code.

A variant of this is to use a build number, and this often comes from a build server e.g if you use TeamCity or similar, it will assign a unique build number to each build and that again is embedded in the code.

In my current project we use both. We manually agree and configure a version number (1.0.20, say) and the build engine additionally determines the build number. That way it's clear what sort of features are in that build (via the version number) but the build number identifies precisely which revision. We embed both in a properties file, and embed that in the deliverable, which knows how to read and report that.

Your Answer

