Getting started

Initial setup

The first time we run versionah we must supply the initial version number, and optionally a name for the package:

$ versionah set -t c src/version.h 0.2.0
0.2.0
$ versionah set -t c -n my_app src/version.h 0.2.0
0.2.0

Makefile usage

If your project uses make, it is a simple task to add version bumping rules:

$(addprefix version-, major minor micro):
    versionah bump src/version.h $(subst version-,, $@)

The above example makes it possible to call, for example, version-minor to bump the minor component in src/version.h.

Note

If you use automake then you can use the PACKAGE_NAME variable to set the --name value.

libtool example

It is easy to use the versioning information for libtool build rules in make files:

$(LIBRARY_NAME): $(LIBRARY_OBJS)
    $(LIBTOOL) --mode=link $(CC) -o $(LIBRARY_NAME) $(LIBRARY_OBJS) \
        -rpath $(libdir) \
        -version-info `versionah display -d libtool src/version.h`

Using the version information as the libtool interface age requires strict practise in maintaining the semantics of your version data, but doing so provides significant value to your users even if they aren’t using the library interface.

ninja example

An example of usage from within ninja could be:

rule bump_versionah
    command = versionah bump example.txt $component
    description = BUMP $component

build version-major: bump_versionah
    component = major
build version-minor: bump_versionah
    component = minor
build version-micro: bump_versionah
    component = micro

Obviously, being a ninja you would choose to generate the rule and build directives programmatically.

Sphinx example

If you generate your project’s documentation using Georg Brandl’s excellent Sphinx tool, then you have a few options for including the version information.

Import the data

If you’re storing your version data in Python format, then you can simply import the file. Accessing the data directly in your project’s conf.py:

from versionah import _version
# The short X.Y version.
version = '{major}.{minor}'.format_map(jnrbase._version.dict)
# The full version
release = _version.dotted

Note

You may need to mangle sys.path if you can’t import the version file from your conf.py.

Use the versionah output

Another option is to call versionah inside your conf.py:

import subprocess
# The full version
release = subprocess.check_output(["versionah", "versionah/_version.py"])
# The short X.Y version.
version = '.'.join(release.split('.')[:2])

The obvious drawback to this method is that it requires all users who wish to build the documentation to have versionah installed, and is therefore not recommended.

pod2man example

If you generate your documentation using perl’s pod2man, then a sample Makefile rule to include your program’s version information would be:

man.1: man.pod
    pod2man --section=1 \
        --release="`versionah display -d dotted src/version.h`" \
        --date="`versionah display -d date src/version.h`" $< $@

More examples

If you’re using versionah with another common(-ish) tool, then new examples for this section are most welcome. Please consider posting them in an issue or pushing them to a fork on GitHub, so that others may benefit.