Versioning In Software Development

3 min readAug 7, 2023

Software constantly changes. Every month, week, day new versions of different libraries are being released. In this case, our main task as software developers is not to get lost and distinguish software versions correctly. And also to follow best practices by setting versions to our software. I want to introduce you some most and well-known approaches in software development versioning.

But before that, I would like to ask you to support me on my Patreon, so I can do more content.

Semantic Versioning (SemVer)

Long story short, the Semantic versioning principle declares that your software version must consist of three dot-separated numbers and increment each one based on how strong software has changed since the previous version. For example:

12.3.17

Let’s go from the last number to the first.

So, the third number is a Patch version number. We must increment (add 1 to the number) this number in case of bug fixing, that don’t have influence on a software features. For example, correcting spelling mistakes and style errors.

F.e: 9.14.7 -> 9.14.8

The second number is a Minor version number. We must increment it when our software gets more backward-compatible features. After incrementing the minor number, the patch version number must be set to zero.

F.e: 1.2.7 -> 1.3.0

Backward-compatibility means that software which depends on the library that got updates will still work without problems.

The first number is the Major version number. This version is incremented only in case of feature change, that makes software which depends on the library's previous version incompatible with a new library version. After incrementing the major number, the minor and the patch version number must be set to zero.

So 3.12.55 -> 4.0.0

Link to the official docs

Zero Versioning (0Ver)

Zero versioning inherits semantic versioning principles, with the key ideology principle: The major version number always must be 0.

There are no answers to why, but I can assume the main idea is that the software must always be backward-compatible.

I thought it quite a strange idea until I recalled about endless versions of angular, java and all its incompatibility with previous versions and endless argues about which software you should choose.

Link to the official docs

Calendar Versioning (Calver)

Calendar versioning is not as strict as previous ones. The main principle is that the version in calver somehow involves the information about software release date.

It can involve a year at the start of the version or a month, conjunction of these numbers, however you want, you can even include days and seconds. Examples you can find in official calver docs:

Unity — YYYY.MINOR.MICRO. — 2019.4.31
pip — YY.MINOR.MICRO. — 23.2.1
PyCharm — YYYY.MINOR.MICRO. — 2023.1.4

Link to the official docs

Modifiers

Honorable mention is that all your versions can contain modifiers at the end of the actual version like “dev”, “alpha”, “beta”, etc., but it’s not mandatory. For you to know just in case.

For example, 23.12.7-alpha1.