Image Description
Understanding software versions
You've probably seen software with versions such as 1.0, 2.4 or 3.7.2.
They look very official, but what do the numbers actually mean?
The slightly annoying answer is: it depends.
There is no law of software development saying every project has to number releases in exactly the same way. A developer could call the next version 42 if they really wanted to. It might cause a few raised eyebrows, but the version police are unlikely to kick the door down.
Why have versions at all?
A version is really just a label for a particular state of a piece of software.
Imagine somebody emails you and says, "the save button crashes the program." Your first question might be: which version? If the problem happens in version 2.3 but was fixed in 2.4, that little number has immediately told you something useful.
Versions help users know whether they are up to date, help developers keep releases organised and allow other software to say which releases it can work with.
What does 1.2.3 mean?
A three-part version is often read as major, minor and patch. In 1.2.3, 1 would be the major version, 2 the minor version and 3 the patch version.
Notice the word often.
Those names are a convention, not a universal rule. A project is free to give those numbers another meaning. Semantic Versioning, which we cover in another tutorial, is one system that gives MAJOR.MINOR.PATCH a very specific meaning.
Major versions
The first number usually represents the biggest step. Moving from version 1 to version 2 might mean a redesigned program, a major new generation of the product or a change that is not compatible with the old version.
Under Semantic Versioning it has a more precise job: the major number changes when incompatible changes are made to the public API.
Minor versions
The second number commonly represents a smaller feature release. Perhaps version 1.2 gains a new export option, and version 1.3 adds another useful feature. It is still recognisably the same generation of the software, but it has moved forwards.
Patch versions
The final number is commonly used for fixes and small changes. Imagine version 1.3.0 has an annoying crash when opening a particular file. You fix the crash without adding any dramatic new features. 1.3.1 would be a perfectly sensible version for that release.
The dots are separators
This catches people out when they first meet version numbers: they are not decimal numbers.
1.10 can quite happily come after 1.9. Read it as version 1, release 10, not as the decimal number one point ten.
What about four-part versions?
You may see versions such as 1.2.3.456. The extra part might be a build number, revision number or something else entirely. Again, the project decides what its version means.
This is why documentation matters. If you create your own versioning system, write down the rules somewhere. Future you will be grateful. Future you has enough problems already.
Version numbers are not quality scores
Version 1.0 does not mean "perfect" and version 0.9 does not automatically mean "bad". A version tells you where software is in its own release scheme; it is not a review score.
Likewise, version 20 is not automatically better than somebody else's version 3. The numbers only make sense in the context of that project.
Have a go
Suppose your program is version 1.4.2. You fix a small bug. What would you call the next version? What if you then add a new feature? What if you redesign something in a way that breaks compatibility?
There is not one correct answer unless you have chosen a defined system. If you decide to use Semantic Versioning, however, those questions suddenly have rules. That's where we're heading.
Next, have a look at alpha, beta and release candidate versions, then we'll get more precise with Semantic Versioning.