[quickthrower2]

While this is probably satire, I sort of agree with it!

I always thought you just need two numbers, a.b

You increment b when you change something in a backwards compatible way.

You increment a when you make a breaking change.

If you are used to semver, it is like ditching the minor version and calling it a patch.

a.b is if course isomorphic to the 0.a.b system mentioned here.

The disadvantage is downgrading patch-only in semver may now be breaking change in twover but that is a rare edge case IMO.

[zajio1am]

> You increment b when you change something in a backwards compatible way.

Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users.

For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible development, while 'c' is for targeted bugfix releases, which are hopefully devoid of such behavioral changes.

[quickthrower2]

I think you have changed my mind, thanks!

[conradludgate]

It depends on the library. I personally like the minor vs patch distinction. If I see a patch version I might update immediately because I don't want a known bug in my application, but if I see a new minor feature version I might wait a bit

[diarrhea]

Same, but note a minor version encompasses all patches since the last release as well. You could have a single feature and countless bug fixes, but it will only show up as a meagre minor bump, with a suspicious zero in the patch field.

[kzrdude]

In theory the patch verison should be painless and always a given upgrade. The minor version might have at least the same number of important bug fixes, it's just coming with a different cost of having larger changes as well.

Some fixes only come with larger changes. Like the recently posted rust regex 1.9 release. Only a rewrite of the library fixed some long-standing issues.