Have you ever wondered how to choose a version number for your software?
For example, the latest macOS release Big Sur has version 11.0. macOS 10.0 (known as Mac OS X Public Beta) was released in 2000, so for the last 20 years, Apple has been incrementing macOS version from 10.0 to 10.15.4.
It is a common practice to track changes by their significance or getting closer to a maximum viable product. Though, surprise surprise, some projects skip numbers. Like, Microsoft Office moved from 12 to 14, Maximo Series 3 → Series 5, SUSE Linux started at 4.2, etc.
In semantic versioning, you can meet major.minor.patch approach, which lets notify on the release functionality and value of the changes (increasing major means breaking changes, while increasing minor and patch mean a medium and low level of changes, accordingly).
major.minor.patch (like 1.0.4)
It speaks about the developers’ attention to detail or marketing reasons as well. You can jump from, let’s say, App 3 to App 7 or move slowly from App 3 to App 3.86. Many open-source projects start versioning with numbers less than 1 to indicate that the product is not perfect yet.
With Themis 0.13.0 open-source high-level cryptographic library update, we have realised what a long way we came through and how high is the star we are hitching our wagon. Themis was released 5 years ago with 0.9 version. And now, when Themis is used by many developers and protects data in numerous systems, we still see a room for improvements.
With every release we're introducing changes that help developers to protect users data while spending less time on configuring cryptography and preventing nasty errors.
And what about you? What software versioning says for you? Which approach do you prefer?
Top comments (3)
By the way, recently we discovered that OpenSSL versioning requires special care in many applications. You know, OpenSSL has versions like "1.0.2u", which is not really semver.
cossacklabs.com/blog/openssl-semve...
He-he, when new macOS was beta-released, many places in Apple code still had "10.16" as version string, and only after month later, code was updated to use "11.0".
Software versioning is a complicated engineering<>marketing<>pr thing.
Within Rust proper semantic versioning is kind of required, but not enforced. So when going from 1.5.10 to 1.6.0 for example it's expected anything depending on it can update without problems.
But this is hard to guaranty, and sometimes issues are created to mark the release as breaking with hindsight.