7 ms·

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 semve

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.

CorrectHorseBat 4y ago
The kernel has never used semver, and it doesn't have to because it never breaks userspace.
- szastamasta 4y ago
  Wasn’t it that version 2.xx was introduced due to incompatible changes? At least it’s what i remember.
  - broodbucket 4y ago
    Dunno, but 2.x was ~20 years ago, things are different now
    - szastamasta 4y ago
      Sorry, it looks I’m a bit old :P
      - jlokier 4y ago
        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 :-)
        usr1106 4y ago
        But 2.6.39 "only" 11 years ago. I would nearly bet that there are still vendors shipping 2.6.x kernels in their embedded systems today. Probably rare...
  - CorrectHorseBat 4y ago
    Don't know about 2.0, can't find anything about it. I know 2 -> 3 was due to changes in development, not breaking of userland.
    - usr1106 4y ago
      No, the change from 2.6.39 to 3.0 had absolutely no meaning. Changes to the development model happened early in the 2.6 series.
  - rodgerd 4y ago
    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.
- froh 4y ago
  indeed. and also for libraries semver is happily alive and thriving.
- jlokier 4y ago
  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.
deleted 4y ago
[deleted]
yjftsjthsd-h 4y ago
> 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)
GoblinSlayer 4y ago
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.
Lvl999Noob 4y ago
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.

CorrectHorseBat 4y ago

The kernel has never used semver, and it doesn't have to because it never breaks userspace.

szastamasta 4y ago
Wasn’t it that version 2.xx was introduced due to incompatible changes? At least it’s what i remember.
- broodbucket 4y ago
  Dunno, but 2.x was ~20 years ago, things are different now
  - szastamasta 4y ago
    Sorry, it looks I’m a bit old :P
    - jlokier 4y ago
      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 :-)
      - usr1106 4y ago
        But 2.6.39 "only" 11 years ago. I would nearly bet that there are still vendors shipping 2.6.x kernels in their embedded systems today. Probably rare...
- CorrectHorseBat 4y ago
  Don't know about 2.0, can't find anything about it. I know 2 -> 3 was due to changes in development, not breaking of userland.
  - usr1106 4y ago
    No, the change from 2.6.39 to 3.0 had absolutely no meaning. Changes to the development model happened early in the 2.6 series.
- rodgerd 4y ago
  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.
froh 4y ago
indeed. and also for libraries semver is happily alive and thriving.
jlokier 4y ago
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.

deleted 4y ago

[deleted]

yjftsjthsd-h 4y ago

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

GoblinSlayer 4y ago

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.

Lvl999Noob 4y ago

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.