8 ms·

The first number being changed doesn't mean anything in particular, it's just like another release. Check the release post for 5.0: https://lkml.org/lkml/2019/

The first number being changed doesn't mean anything in particular, it's just like another release. Check the release post for 5.0: https://lkml.org/lkml/2019/3/3/236 https://lkml.org/lkml/2019/3/3/236

nicce 4y ago
So we can conclude, that the the big star of open source is not enforcing the child of open source :( Ref SemVer: https://semver.org/ https://semver.org/
- dual_dingo 4y ago
  I don't think SemVer is an appropriate versioning scheme for the Linux kernel due to the extremely large number of subsystems that make up the whole.
- dcminter 4y ago
  The unofficial motto of the Linux kernel is "Don't break userspace" so semver wouldn't be useful.
  - mort96 4y ago
    And what's more, the second unofficial motto of the Linux kernel is "break kernel space"; they don't make any attempt at keeping in-kernel APIs stable. So if they followed semver for userspace, they'd be on 1.9000.0, if they followed semver for kernel space they'd be on 9000.0.0.
  - OJFord 4y ago
    There's value, albeit less in the minor vs patch distinction I think. So you could imagine a world in which SemVer came first, Linux uses it, and we're on 1.5.19 but usually drop the 1. because we've agreed there'll never be a v2.
    - bonzini 4y ago
      That's pretty much the state of the 3.x releases, but at some point numbers got big.
      - School-Cotton 4y ago
        I’d say it was the stage of the 2.6.x series.
        bonzini 4y ago
        In 2.6.x patch levels were the fourth number in the version, not the third.
    - School-Cotton 4y ago
      What would be the point of that?
- lallysingh 4y ago
  There aren't breaking changes.
- OJFord 4y ago
  That's one way of doing it, not the only way, and only tangentially related ('it can be useful to' sort of relationship) to open source.
  - frou_dh 4y ago
    Some developers (younger ones?) seem to think that the SemVer spec is a law of the universe, when in reality it's just something a GitHub guy put into the mix in the 2010s.
    - nicce 4y ago
      While it is not the law, it is the only reasonable attempt to solve dependency issues. If the software gets an major release when author feels like it, then version itself tells nothing about the changes. Then dependant software can never estimate the impact of update. I agree that Linux Kernel is a bit different, since it sits on top of everyrhing, but still.
      - bzxcvbn 4y ago
        > Then dependant software can never estimate the impact of update. They can read the changelog. And if they can't be bothered to read the changelog, then why even update?
        bombcar 4y ago
        Semver is a bandaid on a gaping chest wound, that can best be summed up as "major version number changes may break everything, or they may not, but minor version numbers might not break everything, but they may." It's more of a philosophy than a law, and it can't really be relied on that much; as often the developers themselves can't accurately predict what is a major breaking change and what isn't. The Linux kernel itself has some baggage from the 2.4/2.6 era that Linus is explicitly walking away from.
        nicce 4y ago
- School-Cotton 4y ago
  I find it irritating when people quote semver like it’s some kind of law. It’s a random protocol someone came up with that some other people decided to follow. It’s nowhere near a de facto standard for version numbers: plenty of software has non-semver version numbers (in fact, this applies to all software I have worked on so far in my career!)
  - coldpie 4y ago
    I think it's pretty clear semver doesn't really have a place in modern software. Except for Microsoft, no one cares about backwards compatibility, which semver is all about. All software is continually developed, every release contains both new features and bug fixes, which violates semver. The vast majority of software has a meaningless "1." or "0." tacked to the front to try to satisfy semver, until the project gets bored of typing it and just drops it. I think most software should just have date-based versioning. It fits the development models we actually use far better, and actually communicates useful information to the user, unlike semver. Are you running a kernel from 2016? Might wanna update that.
    - nicce 4y ago
      SemVer has significant benefit for package manager world. Many argue that why don’t you just read a changelog, but that is not the point. Package manager should know whether it can update some dependency to later version safely, without some guy always manually hardcoding the suitable version. It is everywhere. In Arch Linux, Debian, Pip and Cargo. They all rely on versions which itself should describe the impact of the change. If there is no standard, then it is always risky to update. On Debian it means manually testing every package. In Arch you accept the risk. If everyone would follow version schema, then you could trust the number in most of the cases. My original message was a bit joke which some missed, but SemVer has a place and need. > All software is continually developed, every release contains both new features and bug fixes, which violates semver. Combination of them is not violation. Overall impact of the change should be described with the correct increment. It does not matter how do you categorise the content of the change.

nicce 4y ago

So we can conclude, that the the big star of open source is not enforcing the child of open source :( Ref SemVer: https://semver.org/ https://semver.org/

dual_dingo 4y ago
I don't think SemVer is an appropriate versioning scheme for the Linux kernel due to the extremely large number of subsystems that make up the whole.
dcminter 4y ago
The unofficial motto of the Linux kernel is "Don't break userspace" so semver wouldn't be useful.
- mort96 4y ago
  And what's more, the second unofficial motto of the Linux kernel is "break kernel space"; they don't make any attempt at keeping in-kernel APIs stable. So if they followed semver for userspace, they'd be on 1.9000.0, if they followed semver for kernel space they'd be on 9000.0.0.
- OJFord 4y ago
  There's value, albeit less in the minor vs patch distinction I think. So you could imagine a world in which SemVer came first, Linux uses it, and we're on 1.5.19 but usually drop the 1. because we've agreed there'll never be a v2.
  - bonzini 4y ago
    That's pretty much the state of the 3.x releases, but at some point numbers got big.
    - School-Cotton 4y ago
      I’d say it was the stage of the 2.6.x series.
      - bonzini 4y ago
        In 2.6.x patch levels were the fourth number in the version, not the third.
  - School-Cotton 4y ago
    What would be the point of that?
lallysingh 4y ago
There aren't breaking changes.
OJFord 4y ago
That's one way of doing it, not the only way, and only tangentially related ('it can be useful to' sort of relationship) to open source.
- frou_dh 4y ago
  Some developers (younger ones?) seem to think that the SemVer spec is a law of the universe, when in reality it's just something a GitHub guy put into the mix in the 2010s.
  - nicce 4y ago
    While it is not the law, it is the only reasonable attempt to solve dependency issues. If the software gets an major release when author feels like it, then version itself tells nothing about the changes. Then dependant software can never estimate the impact of update. I agree that Linux Kernel is a bit different, since it sits on top of everyrhing, but still.
    - bzxcvbn 4y ago
      > Then dependant software can never estimate the impact of update. They can read the changelog. And if they can't be bothered to read the changelog, then why even update?
      - bombcar 4y ago
        Semver is a bandaid on a gaping chest wound, that can best be summed up as "major version number changes may break everything, or they may not, but minor version numbers might not break everything, but they may." It's more of a philosophy than a law, and it can't really be relied on that much; as often the developers themselves can't accurately predict what is a major breaking change and what isn't. The Linux kernel itself has some baggage from the 2.4/2.6 era that Linus is explicitly walking away from.
        nicce 4y ago
School-Cotton 4y ago
I find it irritating when people quote semver like it’s some kind of law. It’s a random protocol someone came up with that some other people decided to follow. It’s nowhere near a de facto standard for version numbers: plenty of software has non-semver version numbers (in fact, this applies to all software I have worked on so far in my career!)
- coldpie 4y ago
  I think it's pretty clear semver doesn't really have a place in modern software. Except for Microsoft, no one cares about backwards compatibility, which semver is all about. All software is continually developed, every release contains both new features and bug fixes, which violates semver. The vast majority of software has a meaningless "1." or "0." tacked to the front to try to satisfy semver, until the project gets bored of typing it and just drops it. I think most software should just have date-based versioning. It fits the development models we actually use far better, and actually communicates useful information to the user, unlike semver. Are you running a kernel from 2016? Might wanna update that.
  - nicce 4y ago
    SemVer has significant benefit for package manager world. Many argue that why don’t you just read a changelog, but that is not the point. Package manager should know whether it can update some dependency to later version safely, without some guy always manually hardcoding the suitable version. It is everywhere. In Arch Linux, Debian, Pip and Cargo. They all rely on versions which itself should describe the impact of the change. If there is no standard, then it is always risky to update. On Debian it means manually testing every package. In Arch you accept the risk. If everyone would follow version schema, then you could trust the number in most of the cases. My original message was a bit joke which some missed, but SemVer has a place and need. > All software is continually developed, every release contains both new features and bug fixes, which violates semver. Combination of them is not violation. Overall impact of the change should be described with the correct increment. It does not matter how do you categorise the content of the change.