I think it's pretty clear semver doesn't really have a place in modern software. Except for Microsoft, no one cares about backwards compatibility, which semver is all about. All software is continually developed, every release contains both new features and bug fixes, which violates semver. The vast majority of software has a meaningless "1." or "0." tacked to the front to try to satisfy semver, until the project gets bored of typing it and just drops it.
I think most software should just have date-based versioning. It fits the development models we actually use far better, and actually communicates useful information to the user, unlike semver. Are you running a kernel from 2016? Might wanna update that.
SemVer has significant benefit for package manager world.
Many argue that why don’t you just read a changelog, but that is not the point. Package manager should know whether it can update some dependency to later version safely, without some guy always manually hardcoding the suitable version.
It is everywhere. In Arch Linux, Debian, Pip and Cargo.
They all rely on versions which itself should describe the impact of the change. If there is no standard, then it is always risky to update. On Debian it means manually testing every package. In Arch you accept the risk. If everyone would follow version schema, then you could trust the number in most of the cases.
My original message was a bit joke which some missed, but SemVer has a place and need.
> All software is continually developed, every release contains both new features and bug fixes, which violates semver.
Combination of them is not violation. Overall impact of the change should be described with the correct increment. It does not matter how do you categorise the content of the change.
It's often a change in interface. If you build from source, old code simply won't compile with new incompatible interface, and won't get to the testing stage.
The impact comes from the dependencies you are using.
Depending how the software is made, it can be noticed early on build time.
But it can also be noticed just on runtime, e.g. dynamic libraries, which is hopefully noticed on testing stage.
However, how it impacts downstream, the dependents of your software, cannot be tested. You can only inform about it. For people, with changelog.
For automated systems, with version number. But if you do not follow systematic version numbering, you fail to inform automatic systems. They update to the later version of you software and dependents will break.
That's "Linux" the kernel, not the operating system. No one building a 'modern' desktop OS on top of that kernel cares. Download a 20 year old Linux binary and try running it on a random up to date linux distro. Unless it's a trivial program it will almost certainly fail.
> one cares about backwards compatibility, which semver is all about.
Interesting. I'd characterise it more as 'responsibly breaking backwards compatibility'. Just a tool to communicate the nature of changes, a really (really) brief summarising changelog - what's included, breaking changes, non-breaking new features, or just misc. fixes?
I quite like it, but I tried to phrase my top-level comment not to be about it specifically. It would have surprised me to learn that Linux used 'semver' - that doesn't mean there's no semantic meaning to the version numbers it uses though.
> backwards compatibility, which semver is all about
It's not about maintaining backwards compatibility. It's about making it explicit when you break compatibility. Whether you do or not is completely up to you - semver doesn't care.
I think most software should just have date-based versioning. It fits the development models we actually use far better, and actually communicates useful information to the user, unlike semver. Are you running a kernel from 2016? Might wanna update that.