Hacker News Reader

Comment by reisse | Hacker News Reader

If Linux used semver, it'd never go past 1.x. Public kernel API never breaks, ever. So what's the point for semver?..

If Linux used semver

Solaris tried something like this for a while. While their competitors were releasing versions 4, 5 and 6 of their OS, Solaris was releasing version 2.4, 2.5 and 2.6. This made it look like they were just doing minor updates to Solaris, when they were in fact major new versions. Eventually they gave up and renamed solaris 2.7 to Solaris 7 just to keep up with the version numbering.

Not because of competition, but Emacs¹ and MiKTeX² also dropped the major number from their versioning schemes.

¹ https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS.1-...

² https://github.com/MiKTeX/miktex/issues/554

Java did it ages ago (1.5 and 1.6 became 5 and 6; I forget if 7 and 8 were also 1.7 and 1.8 originally)

> If Linux used semver, it'd never go past 1.x. Public kernel API never breaks, ever.

Yep:)

> So what's the point for semver?..

Exactly that: To trumpet it to the world - this project never broke compatibility, accept no substitutes.

Except it did. Multiple times. And I vaguely recall one incident where they couldn’t revert although maybe I’m misremembering.

> The Linux ABI definition is both fuzzy and controversial. Some ABI breaks are unavoidable. [1]

[1] http://she-devel.com/Chaiken_LinuxABI.pdf

Ultimately it sounds like the policy is actually 0 “reallly bad ABI breaks” where “bad” is a subjective evaluation of how many bug reports they get or breaking something foundational (eg pulse audio). It’s just not possible to freeze the ABI because people may have found kernel bugs and worked around them and the fix for the kernel bug breaks the workaround. That’s what Hyrum’s law means and the Linux kernel doesn’t have a unique solution here. Don’t get me wrong. They do a fantastic job all things considered. But the “never break ABI” is more marketing than a hard and fast rule (but yes they generally get as close as is feasible to sticking to it)

ABI ≠ API. The ABI is a property of the program, the compiler (including options used during compilation), and the target platform. Semver only concerns itself with API, ABI isn't even a consideration there.

I doubt many practitioners of semver would agree that changing the behavior of a function in a breaking way would technically be a ok because it only covers the API signature. Semantic versioning frequently means “non-major version is ok to blindly update and not only will the code still compile it’ll also behave the same way at runtime”, branding notwithstanding.

“Public api never breaks” as OP posted, for example, is a reference to the Linux ABI policy

Linux kernel user facing APIs never break? It really depends on what you consider user facing. If you’ve ever relied on or considered sysfs to be a user facing API there have been numerous and severe breakages over time in the Linux kernel.

I think gp was referring to Linus Torvalds somewhat famous mantra to "never ever break userland, ever"

Quite a few engineers has seen the sharper side of his tongue for not taking that mantra seriously enough

Sure, he does rant about it, but the user facing APIs break constantly none the less.

A relevant example from yesterday: https://lore.kernel.org/lkml/CAHk-=wjifBVf3ub0WWBXYg7JAao6V8...

Linux is more than just an API, its support of platforms changes over time for example

Sure, the point is that semver cares only about the API. Thus it's not really applicable to anything but userland libraries.

Reply on news.ycombinator.com