Background

I maintain many projects, both my toy stuff on GitHub and more serious things at the office. While skipping around in my editor to increase a version number I came to the blindingly obvious realisation that I shouldn’t be doing this manually.

Bumping or querying version numbers should be a zero thought process. I shouldn’t need to remember the regex needed to make my editor jump to the version identifier in any given file. I shouldn’t need to resort to various C-a and C-x contortions in vim or formulating complicated lisp functions with number-to-string and string-to-number in emacs.

Now versionah is born, and I should be able to realise those dreams!

Version numbers

This — for some — is a very complicated topic, but not for me. Version numbers are made of three components; major, minor and micro. All three components are natural numbers; no exceptions.

If you find version numbers like 0.6c11 acceptable then versionah is not for you.

Note

If you like version numbers with two or four integer components then versionah can be for you too. Support was added in 0.6.0, but that doesn’t mean you have to use it!

PEP 386

The version numbering scheme supported by versionah is a very small subset of LooseVersion defined in PEP 386. It isn’t compliant with StrictVersion because of the 4 component support, but support for packages in the wild is much more important to me.

Versioning policy

Beyond the simple rule above you’re free to do as you wish, but consider this a plea for a sane versioning policy.

Major component

Increment the major component for all backwards incompatible changes.

Minor component

Increment the minor component for all backward compatible additions.

Micro component

Increment the micro component for all bug-fix releases.