> Semver in applications tells you important things such as how different a release is and how much incompatibility to expect
I disagree that it tells you either.
Release A adds massive new features, with hundreds of thousands of lines of new code, dozens of new third-party dependencies, but with zero (intentional) backward incompatibilities – increment minor version only.
Release B only removes one tiny obscure legacy feature which almost nobody used. But that's backward incompatible, so must increment the major version.
For any user considering whether to upgrade, release A is almost surely a much bigger risk than release B – yet semver tells them that B is major whereas A is only minor.
Similarly, consider release C which removes dozens of features, many of which are widely used. Obviously release C is a much bigger risk than release B which only removes a single obscure legacy feature – but since semver treats backward compatibility as a binary "yes-no", it fails to communicate that release C is a much bigger deal than release B.
> True, semver doesn't literally tell you how old a release is, but how often is that important?
Well, if the year is 2023, and I'm running WhateverApp 2010, I instantly know I'm running a really old version, and ought to look into whether there is a newer one. Whereas, if I'm running WhateverApp 2021, it is only two years old, so I'll put researching newer versions a lot further down my priority list.
I disagree that it tells you either.
Release A adds massive new features, with hundreds of thousands of lines of new code, dozens of new third-party dependencies, but with zero (intentional) backward incompatibilities – increment minor version only.
Release B only removes one tiny obscure legacy feature which almost nobody used. But that's backward incompatible, so must increment the major version.
For any user considering whether to upgrade, release A is almost surely a much bigger risk than release B – yet semver tells them that B is major whereas A is only minor.
Similarly, consider release C which removes dozens of features, many of which are widely used. Obviously release C is a much bigger risk than release B which only removes a single obscure legacy feature – but since semver treats backward compatibility as a binary "yes-no", it fails to communicate that release C is a much bigger deal than release B.
> True, semver doesn't literally tell you how old a release is, but how often is that important?
Well, if the year is 2023, and I'm running WhateverApp 2010, I instantly know I'm running a really old version, and ought to look into whether there is a newer one. Whereas, if I'm running WhateverApp 2021, it is only two years old, so I'll put researching newer versions a lot further down my priority list.