Show notes

Software Versioning


2 of the things that versioning formats are trying to balance are

  • Being human friendly
  • Being machine friendly


Semver is trying to avoid falling into “dependency hell”.

  • If the dependencies are not well defined you will necessarily get bitten at some point by upgrading a dependency that will break something in an unexpected way.
  • According to their documentation, the inverse would be

    if the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package).


From the NPM documentation

To keep the JavaScript ecosystem healthy, reliable, and secure, every time you make significant updates to an npm package you own, we recommend publishing a new version of the package with an updated version number […] that follows the semantic versioning spec. Following the semantic versioning spec helps other developers who depend on your code understand the extent of changes in a given version, and adjust their own code if necessary.

First release New product Start with 1.0.0
Backward compatible bug fixes Patch release Increment the third digit 1.0.1
Backward compatible new features Minor release Increment the middle digit and reset last digit to zero 1.1.0
Changes that break backward compatibility Major release Increment the first digit and reset middle and last digits to zero 2.0.0

No semver

Semver tries to optimize for machine readability. A simple program can read the format string and understand if the new version of the dependency can be used. But that’s not optimal for humans.

Semver is trying to compress too much data in too few numbers.

  • What’s a breaking change?
    • Do I need to reorder a parameter on one single function
    • Or do I need to rewrite my whole application?
  • If this update will break 0.01% of the applications using the dependency, should it be a new major version? What about 10%?

Semver might give a false sense of safety to developers. Version numbers should try to replace a good changelog entry.


When there’s a new release, they just increase the version number and it’s done. There’s no special meaning to the number other than it’s a new number and they don’t promise anything about compatibility. The current version is 245.


Or also known as Calendar Versioning.

  • Not trying to be as strict as semver
  • Ubuntu using 20.04 (YY.MM). Since the beginning
  • Windows use to be XP service pack 2
    • Moved to Windows 10 Threshold, Redstone, 19H1, 19H2, 20H1, 20H2, 21H1
  • Unity used Semver-like until 5 and in 2017 they switched to calvar. So now it’s Unity 2020.1.1

Fedora packages

Fedora has an interesting challenge compared to the others we talked about since they are bundling other people softwares which might be using different ways of naming their versions.

The overriding goal is to provide sequences of packages which are treated as updates by RPM’s version comparison algorithm while accommodating varied and often inconsistent upstream versioning schemes.

Their simple versioning scheme

They consists of one or more version components, separated by periods. Each component is a whole number, […]. The rightmost component can also include one or more ASCII letters, upper or lower case. The value of a component must never be reduced (to a value which sorts lower) without a component somewhere to the left increasing

They have a bunch of other parts in their versioning format to accommodate for more complex problems.


TeX is a formatting system written by Donal Knuth.

Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π

Knuth decided to do that to represent the fact that there will never be any new feature. Every new release will only fix bugs.


Firefox and Chrome are fighting over who has the biggest number. We were on Firefox 3 for multiple years, but starting at Firefox 4, they started to frequently release new versions with new version numbers. Now, the release dates for Firefox and Chrome are known in advance and are stable.

For example, we know that for Firefox approximately every month a new version starts in nightly, one is moved to beta and one is released.


The Linux kernel bumped the version number from 2.6.39 to 3.0.0, because the 39 was getting a bit large, and to commemorate Linux’ 20th anniversary.

But I’d like to point out (yet again) that we don’t do feature-based releases, and that “5.0” doesn’t mean anything more than that the 4.x numbers started getting big enough that I ran out of fingers and toes.