Hacker News Reader

Comment by tomphoolery | Hacker News Reader

Is there a specific reason that the Linux kernel team has given for not adopting semantic versioning? Or has the discussion just never been started?

View on HN

As others have chimed in, while working extremely well for _libraries_, which I believe Semantic Versioning was really proposed for in the first place anyways, it does not work or necessarily make sense for Kernels which are kind of a very special kind of library.

Once matured, kernels tend to never break backwards compatibility (or try very hard not to), and rarely track bug fixes with individual numbering. Often many changes are lumped into a single version update, because so many changes are already happening across many different subsystems.

I suppose also, now that I think about it, Semantic Versioning works much better for smaller scoped and smaller scale projects (like well scoped and designed libraries). The kernel is such a large piece of software almost like a collection of libraries hidden behind a single set of matures APIs that incrementing counters for every bug fix or tiny change doesn't make sense---and as has been established, major numbers would just never bump.

This makes sense, but then why have a version number that looks like semantic versioning? If they are randomly jumping major versions (2.6 -> 3, now to 4) they might as well drop the major version altogether.

Why not go for a release number (e.g. r85) and a patch number for hotfixes (e.g. r85.2)?

There are no hotfixes (from Linus, the stable branches are a different matter). And basically the release is just a snapshot of updates that happen to build together with some nudging and silly letters from Linus.

Best would be to just go and use a year.month number. 2014.12, 2014.02, 2015.04. But ultimately, it's just a semi-unique identifier with a lot of context that one should be aware of. (And it's not like you can go and buy a Linuks 4 in stores right now, or just put it into your requirements.txt. So confusion is very minimal, it's just a "tag".)

I actually thought that, but you'd still end up with things like 2014.12-r7 because you end up creating different versions when you backport fixes.

Because the semantic versioning meme appeared tens of years (!!) after people started using x.y.z versions for software (including Linux).

"What version of Linux are you running?"

"Uh, 2.something."

"Well, that's a span of 15 years right there. 2.what?"

"Uh, 2.6.something."

"Okay, that's a start. That narrows it down to a span of 8 years, almost a factor of two in improvement."

If they were to adopt semantic versioning, they'd NEVER bump the major version number in a hundred years. Think about this: when was the last time that changes to the Win32 API broke your application? Linux is also like that.

With this scenario in mind, could it make more sense to adopt a version scheme incorporating the initial release date (or considering the kernel workflow, merge window date), similar to ubuntu? "I'm running linux 15.2.4, aka. the 4th update to the kernel from Feb 2015"

Plenty of Linux changes have broken my system - removal of devfs, breaking of not only binary module compatibility but even source compatibility (e.g. I can't build my qc-usb webcam driver any more).

The stable API/ABI is for _user_ space, not kernel space.

If the userspace API/ABI never changes, maybe a more useful use of the version number would be to reflect kernel API/ABI changes?

There is no in-kernel API/ABI. The Kernel team is very vocal that the only interface that exists for the kernel is the userspace systemcall/filesystem interface, and any code that wants to use anything beyond that really should live in the kernel tree. Things like the nvidia closed-source driver that hooks into the kernel itself are not using any API/ABI, they are basically just hooking into structures where the people maintaining those structures don't just not care about being compatible, but are actively hostile to people relying on their code remaining same across versions.

Yep, if we were to say that in kernel struct changes mean a major release in semantic versioning, there would never be anything but major releases.

Even though for all of them the user space api wouldn't break. So yeah, I think the people harping on semantic versioning don't quite understand the reason its not a good fit for an os kernel.

Java had been 1.x since 1996. Sun took to using the minor version as the everyday name - so 1.8 is Java 8 - and that seems to have worked okay so far.

I have no idea what Oracle or whoever will do if 2.0 ever does come out. But I doubt it ever will.

Probably because of this:

So far, the arguments against it seem to have been "major numebr should go with a major new feature or breaking of compatibility", which just shows how little people know. We don't break compatibility, and we haven't done feature-based releases since basically forever.

Because Kernel changes should never break backwards compatibility, so that would mean the major version number would never change, making it worthless.

And you'd end up with very large numbers for the minor numbers, which Linus seems to dislike.

Linux used to version in a different way which was somewhat semantic, but actually moved away from it because it's significantly less useful for kernels, as explained in other replies.

Reply on news.ycombinator.com