On Software: Version Numbers

Just a little train of thoughts on the topic of numbering versions of software products (and by that, I mean client-based, locally installed programs, not webservices which are always considered to be in a state of flux and where maybe timestamps are a better format).

The topic came up when I revised the plans for future RandFill releases.


First, a quick overview of the most common methods for version numbering:


All in all, it’s not as simple as it seems at first.

For my small projects, I see a certain charme in just going from release 1 to 2 to 3 instead of ranking the impact of the latest changes. RandFill has a rather narrowly defined focus on what it should be able to do and it’s not a library or supports plugins (yet), so breakage of APIs and binary compatibility are of no concern either.

The core of the application will remain the same: There will be certain enhancements and bugfixes, but will that ever justify a jump to a 2.x.x version? You’ll probably rather see a version 1.89.23 than a 2.3.11.

This post is supposed just to be food for thought and I haven’t decided yet which model to follow:
For the next couple of releases of RandFill, I’ll stick with the X.Y.Z scheme — after that, I’ll probably reevaluate it again; maybe timestamps will be the right choice…