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.

Overview

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

• Major.Minor (e.g. 1.0 or 2.37)

  This was the first way to enumerate releases that I encountered, and for a while it made perfect sense:
  For big changes, the major version gets bumped, for smaller ones, the minor version number increases.

  But over time, my view on it shifted: What’s considered a big change? Is it a big change when the whole user interface changes, but nothing of the back-end? Maybe the UI is abstracted enough that a designer just spent 10 minutes rearranging buttons and layouts in a fancy tool.

  So for the users it will appear to be a heavy difference, but actually it’s not in terms of functionality.

  Marketing also plays a role here: Occasionally it appears to be appropriate to jump two major versions ahead and make a statement (“still alive and kicking!”).

  Another point: Are those two integers or is it a floating-point number?
  I’m german, so that wasn’t a question for me in the beginning; floating-point numbers use commas here, dots seperate segments (e.g. in a book’s table of contents).
  But then I learned that in the USA and other countries, floating-point numbers use dots. So what comes after 1.9: 2.0 or 1.10? What’s newer: 1.9 or 1.10?

  And even though the common understanding is that the major and minor version number are two integers, I’ve also seen it being treated differently. To avoid confusion, often the product version dodges ambiguous numbers like 1.10 and instead skips to 2.0, regardless if it is technical approriate (cue marketing).

• Major.Minor.Patch[.Build] (e.g. 1.0.3 or 2.56.0.1769)

  Another common method is using three or four part version numbers, with the usually meanings of Major.Minor.Patch[.Build].

  There’s also a guideline for it, called Semantic Versioning; the advantage here being that the ambiguity whether it is a floating-point number or not is gone.

  The Semantic Versioning tries to define exactly the meaning of Major/Minor/Patch, but if you’re writing a standalone program and not a library, does it even matter when you make incompatible API changes? I’d consider a new feature like “upload files to a cloud service” for a tiny tool a worthy reason to bump its major version number, but it probably will not break the API or binary compatibility and therefore, according to SemVer, shouldn’t switch to a new major version.

  So it adds another level of granulation: What is a major or minor change, what merely a patch? Is a bugfix just a patch? And can your build process automatically increase the build number?

• Just-A-Single-Number (34, 35, 36, …)

  That brings me to the recent trend, established by browsers like Chrome and Firefox, of only using one single number for the releases; or at least it’s communictated that way to the public, because internally most of them still use something like Major.Minor.Patch[.Build] version.

Summary

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…