Software versioning hides security updates

In this post I argue that versioning conventions hide the importance of security updates and propose an alternative.

Introduction to versioning

There are two popular conventions for versioning software:

• Semantic versioning or SemVer: Useful to know which versions bring breaking changes or new features
• Calendar versioning or CalVer: Useful to know when each version was released

The chosen versioning system should depend on the type of software.

• For a web API, it makes sense to use SemVer, however the patch number might not be necessary.
• For Desktop software that releases at a fixed schedule, it makes sense to use CalVer
• For software in which only the latest version is supported, it makes sense to mix both versioning systems. For example: YY.REVISION would indicate the year of release and the revision.

In addition, build numbers can be appended with a + to the version. They can contain for example the number of commits since the last version plus the commit short hash: 19.23+7:3f0b4d1

Security Versioning

Usually, critical security fixes come as a patch, so only the least significant number is increased. Suppose there is a software with version 3.1.0 which is later updated to 3.1.1. By comparing the version numbers, you may think that the update only has minor bug fixes, but the difference may be a critical security vulnerability that can compromise your computer.

Therefore, I propose SecVer, a versioning system that puts security first. The format would be S.v, where S is the security release number, and v is the version number, which can also comprise a major and a minor. So following the previous example, the version numbers could be instead 0.3.1 and 1.3.1. Because S is the first number, users will be more likely to want to update, specially if they understand that there are security updates.