What is in a Version Number?

A series of overlaid scattered numbers in different colors and sizes. Software developers use a series of numbers to describe the version number of each release. These release numbers increase to higher numbers over time as the developer fixes bugs, adds new features, or re-writes the software to meet changes in technology. Described below is the common usage of these series of numbers.

The first purpose is to show progress. So, version 2.0.0 comes after version 1.0.0, or the use of the year to signify the advancing release cycle. In either case these show that one release of a piece of software is different from an earlier release of the software with the same title, such as the Joomla CMS.

Secondly, naturally marketing is a critical reason to have version numbers for software. This provides an opportunity to sell any new features over earlier versions. Thus, version numbers are handed off from software development to product marketing where new versions of software are released with much fanfare.

Finally, major version numbers signify compatibility meaning that by looking at two version numbers for the same piece of software, a user or developer can easily decide on how compatible these two versions are. It is the encoding of that compatibility between versions that gives version numbers meaning. Since semantics is just a fancy word for meaning, this is called Semantic Versioning, or SemVer for short.

Breaking it Down

Now, let’s break down semantic version numbers, which consists of three parts separated by periods (“.”).

Consider 2.4.7, wherein each of these numbers in the version number have a specified meaning that signifies something about the compatibility of the software. They denote the following:

breaking.feature.fix

Breaking: this includes incompatible changes to the software, effectively the new version is not backward compatible with earlier versions.

Feature: identifies when a new feature is added in a backwards-compatible manner.

Fix: includes backwards-compatible bug fixes.

Thus, software below 1.0.0, such as 0.1.0 is considered beta or a work in progress. It is unlikely that this software is stable and should not be used for anything but testing. Most likely new versions will likely break functionality and security vulnerabilities have been patched.

Going forward from there, versions above 1.0.0 are considered the first stable release

And 1.1.0 is the first mew feature release and should not break backward-compatibility.

While 1.1.1 is the first bug fix version and does not break backward-compatibility.

Then as things evolve, when 2.0.0 is released it will likely break backwards compatibility. Typically, when upgrading to this version a 'migration' function will run updating data to be compatible with the new version. The migration is usually a one way trip, thus backing up your data prior to installing the newest software version is absolutely critical.

Let’s reconsider the version 2.4.7 example above, this would be the second edition of the software that likely has broken compatibility with the first edition. At least four new features have been introduced, and seven bug fixes addressed in the fourth feature set of the second edition.