It maybe off-topic, but don’t you think that semver is somewhat dead if even kernel (software everyone depends on) does not use it any more?
According to semver there should be some heavy incompatible changes in this release, while it’s only a regular update.
Maybe we should all just agree that semver is simply a pipe dream and we are never sure that lib update won’t break our app. Or that lib maintainers take compatibility really serious and they don’t break it, like kernel hackers do.
It's not supposed to break userspace, but it does from time to time.
There's a surprising amount of userspace code which has to check the kernel version number because some behaviour has no "feature check" that can be used. On rare occasions that gets tricky when a distro has backported some kernel change to an old kernel version.
Because it's not supposed to be done, most breaking changes are unexpected so it wouldn't be possible to implement semver anyway, or are bug fixes which happen far too often for semver.
More than that, for many years, the odd minor releases were unstable (1.1, 1.3, 2.1, 2.3) and the evens were stable (1.2, 2.0, 2.2, etc). There could definitely be big churn going from 1.2 -> 2.0, 2.0 -> 2.2 and so on.
20 years was a friendly underestimate. 2.x was introduced 26 years ago ;-)
If it helps, I remember the transition from Linux 0.99 to 1.0, the switch to ELF and Glibc, the first non-x86 architecture support, the introduction of kernel modules, threads being a new feature, and the dropping of 386 support - all but the last happened while I was using Linux as my desktop OS at my day job :-)
It's also not clear what it's supposed to be compatible with. There are many compatibility concerns, but semver admits only one. Linux removes and deprecates features and changes driver API too, so you can expect every release to break some things and not break other things.
Semver has its uses. Those uses are not in something like a kernel. A kernel can be considered to be a collection of multiple APIs, with each one have its own audience. Every version brings changes to some of these APIs which makes its a breaking release to some of the audience.
Semver is good for things like libraries that have a single audience. Either the workflow is broken for all of them or none of them (at least mostly). It can also be used for individual APIs. But for systems that are a collection of multiple APIs (kernel, browser, apps, etc), semver starts making much less sense.
> we are never sure that lib update won’t break our app. Or that lib maintainers take compatibility really serious and they don’t break it, like kernel hackers do.
That is extremely unlikely to catch on. It's both annoying and imposes significant costs. It also tends to trap you in early design decisions. (Don't get me wrong, in my dream world where all software was formally designed and written perfectly the first time and orgs gave infinite resources to engineering and addressing tech debt, everyone would use semver and almost nobody would ever pass 1.x - it's just that I don't think it's likely)
According to semver there should be some heavy incompatible changes in this release, while it’s only a regular update.
Maybe we should all just agree that semver is simply a pipe dream and we are never sure that lib update won’t break our app. Or that lib maintainers take compatibility really serious and they don’t break it, like kernel hackers do.