[evmar]

They are following semver: http://semver.org/

So the major version changes whenever they make a backwards-incompatible change.

However, I clicked in their upgrade calculator (linked from the post) and at a glance it appears the incompatible changes are fairly minor.

[usrusr]

But did semver really set out to eradicate all distinction between minor incompatibilities and complete architectural reboots?

So much semver adoption seems to be based entirely on wishful thinking.

  Step 1: hey, perfect drop-in compatibility would be so cool
  Step 2: we can do it, with semver!
  Step 3: we use semver! Yay us!
  Step 4: oh, turns out adopting semver did not make perfect drop in compatibility any easier
  Step 5: don't ever touch that zero between major and bugfix

[ldiracdelta]

Adopting and enforcing usage of semver across teams helps tame some code cowboys that think they can change their library and everyone else should just adjust to their new API. I found it very useful for documenting API changes on an intra-company dependency where the library developers said, "Oh we don't change the API", but actually changed the API in backwards-incompatible ways all the time and made everyone downstream change their code on every release.

[dragonwriter]

> But did semver really set out to eradicate all distinction between minor incompatibilities and complete architectural reboots?

It's explicit terms do, whether or not that's the intent. Backward incompatible is a bright line.

OTOH, I think that exact bright line is the central purpose of SemVer.

[usrusr]

> Backward incompatible is a bright line.

Only as bright as the line between public API and private implementation details that are allowed and expected to change between semver minors. This is not always very clear.

[fknop]

They do actually use every number of semver in a meaninful way.