Major versions, minor, alpha, beta…what’s the difference? A brief guide for a better understanding of software versioning.

Find software version

Before going further, it could be useful to know how to recognize a software version. It’s an essential piece of information during the analysis or reproduction of bugs.

For software with a graphic interface, this information is usually in the menu Help or About.

For websites you should go to the Help or About page. Thus, in VSA, you just should click on your picture in the top right corner of the homepage and click on the About the application link to display the following pop-up window: 

For software that can be used via command line interface, there is often a command like <my_software> --version to display the installed version. Examples: to know the versions installed on a server running Python, Java and PowerShell, use following commands:

Which corresponds to Python 2.7; Java 8 and PowerShell 5.1.

Which version to choose?

It’s usually wise to use the last stable version of a software, which is compatible with your environment (operating system, material architecture). Be careful with licenses problems! Don’t hesitate to consult your client.

Update your software regularly to enjoy bug patches, new functionalities and security patches.

Numbering

Each editor/project is free to use its own numbering.

Semantic Versioning

The X.Y.Z type of numbering is used by lots of programs. 

The Semantic versioning convention suggests the following signification:

• X corresponds to the major version: non-backwards-compatible changes. Major evolutions bring new functionalities, by radically changing the aspect or architecture of the software.
• Y corresponds to the minor version: adding compatible functionalities, general bug corrections, adding some functionalities.
• Z corresponds to the patches: bug correction, security failure patching

This convention is increasingly adopted, notably in the open-source environment, like Python.

Timestamp version

Other pieces of software base their numbering mode on the date/hour of publication. It’s particularly true for open-source and software published at a clearly-defined rhythm.

Microsoft’s software was using this convention for a long time as in Windows 95 (sold in 1995) or Microsoft Office 2013 (sold in 2013). These versions correspond to “open-source” versions and are easy to remember.

Ubuntu software (one of the numerous existing Linux distributions) suggests a new version every 6 months: on April and October. Thus, it’s possible to download last year’s versions, Ubuntu 18.04 and Ubuntu 18.10.

Commercial version and internal version

Some programs have 2 version numbers:

• A commercial or “open-source” version
• An internal version

Indeed, it’s easier to remember the commercial name of a software than its internal version’s.

It’s the case of Microsoft Windows operating system:

Another example, for Oracle databases:

We can see that:

• The “v1” version never existed: The Oracle creator, Larry Ellison, preferred to name the first version of his product “v2” to reassure his clients.
• Oracle uses “marketing” suffixes in product names according to actual trends: I for internet, g for grid, c for cloud.
• Oracle changed from v12 to v18 to harmonize the version number with the year of production.

Versions undergoing testing

Versions currently being tested and in development often use a version number with suffixes like alpha, beta, RC (Release Candidate) according to the development cycle of the software.

These pieces of software in development are mainly used by beta-users or early adopters to send bugs to a higher level early enough. Example software: PHP.

Other software uses a numbering ending in an even number for stable software and an odd number for unstable versions.

In the open-source world there are software with 0.x versions. Often a software doesn’t reach the v1 version until it becomes stable.

Long-term Support

Some software is in LTS (Long-term) version. These LTS versions have a higher maintenance period than the standards version.

These versions are often privileged by firms because they guarantee the availability of patches for many years, without taking the risk of needing to upgrade to a higher version.

Thus, Ubuntu 18.04 LTS has a 5-year maintenance period, while Ubuntu 18.10 has a 2-year maintenance period.

Other examples:

• Jenkins
• Java 8, Java 11

Community/ enterprise edition

Some programs are available in 2 different modes:

• CE mode or Community Edition: open-source software version, free
• EE mode – Entreprise version: the paying version of the same software, with additional functionalities for businesses

Example: Docker 18.09 CE

Anecdotes

Software versions are not safe from oddities

• The PHP language went directly from version 5 to 7. Indeed, PHP 6 never existed, falling victim to its bad reputation during development. Developers preferred to restart from scratch and go directly to PHP 7.
• The Linux kernel has changed its major version in a completely arbitrary manner according the mood of its creator, Linus Torvalds.
• Some editors, like Microsoft avoid proposing software versioned 13 due to the superstition around this number.

Security

Pieces of software are not spared from bugs and security failures. Some institutional websites like the Computer Emergency Response Team (CERT) or the Common Vulnerabilities Exposures (CVE Details) list different vulnerabilities for each software version.

Example: Vulnerabilities known in WordPress 4.9.8

Advice for developers

• If you have created a software, use a convention like the Semantic Versioning
• Keep a list with all the changes (CHANGELOG or Release Notes) for all versions and give it to the production team at the time of deployment
• Manage software dependencies with a special tool (Apache Maven, Python pip, NuGet, npm)
• Analyze your projects regularly to detect obsolete or vulnerable third-party frameworks

Advice for production engineers

• Make sure that the tested version in a testing environment is the same as the one you want to deploy in production
• It’s strongly discouraged to install a non-finalized version in production software (in alpha or beta version)
• Read the list of changes before the deployment of a new version (CHANGELOG or Release Notes)