Ref SemVer: https://semver.org/
It’s a random protocol someone came up with that some other people decided to follow. It’s nowhere near a de facto standard for version numbers: plenty of software has non-semver version numbers (in fact, this applies to all software I have worked on so far in my career!)
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.
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.
That would seem to be contradicted by Linus's "WE DO NOT BREAK USERSPACE"[1].
The Linux community clearly cares for backwards compatibility too.
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.
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.
