4 ms·

"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 sta

"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.

ekimekim 12y ago
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"
lmm 12y ago
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).
- ciupicri 12y ago
  The stable API/ABI is for _user_ space, not kernel space.
  - lmm 12y ago
    If the userspace API/ABI never changes, maybe a more useful use of the version number would be to reflect kernel API/ABI changes?
    - Tuna-Fish 12y ago
      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.
      - mitchty 12y ago
        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.
twic 12y ago
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.

ekimekim 12y ago

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"

lmm 12y ago

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).

ciupicri 12y ago
The stable API/ABI is for _user_ space, not kernel space.
- lmm 12y ago
  If the userspace API/ABI never changes, maybe a more useful use of the version number would be to reflect kernel API/ABI changes?
  - Tuna-Fish 12y ago
    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.
    - mitchty 12y ago
      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.

twic 12y ago

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.