4 ms·

By his own admission, the first two numbers mean nothing. Kernel releases happen on a roughly regular schedule. Date-based versioning is clearly the correct ans

by coldpie 12y ago

By his own admission, the first two numbers mean nothing. Kernel releases happen on a roughly regular schedule. Date-based versioning is clearly the correct answer and I don't know why it's never even discussed.

mitchell_h 12y ago
Linux people have a natural, inbuilt fear, of everything BSD related. Date based releases are evil! That's slightly a joke, but I think in reality the development model that Linus and the other maintainers have created are feature based more than timeline based. As a developer I would enjoy a date based release schedule. I don't follow HEAD closely anymore but it would be easier to keep up the general view I try to keep. BTW; In a way the distributions already do a date based release. RHEL 6. RHEL6.1, RHEL6.2, etc.
- BuildTheRobots 12y ago
  I've seen Linus loose it with devs in the past for breaking backwards compatibility with kernel updates; I'd suggest this also has something to do with it -possibly more so than an inbuilt fear of BSD [1]. I'm failing to find an explanation of how the RHEL numbering scheme is date based -please could you expand? [1] As a long term linux user, I have both fear and bafflement over BSD device naming and the lack of gnu options on standard utils ;)
  - mitchell_h 12y ago
    The numbering scheme isn't date based, but the release schedule is. You can point at RHEL6.3 and say Released "2012-06-20"
    - BuildTheRobots 12y ago
      Not entirely sure what you mean by release schedule. I found this[1] list which lists releases and dates, but (unless I'm being thick,) it's not like they're minor-bumping every x months, it seems to be arbitrary. And if it's arbitrary, I don't see how it matters. If I'm looking up the release date for 6.3 then I may as well look up the release date for 2.6.32...
- protomyth 12y ago
  Which BSD is doing date based releases?
  - mitchell_h 12y ago
    OpenBSD and FreeBSD
    - protomyth 12y ago
      OpenBSD releases every 6 months but does a #.# scheme incrementing the point number each release, so no date in the release number. FreeBSD has not been on a fixed schedule and doesn't use dates in their version numbers.
toyg 12y ago
If you mean having something like "2015.01.13", it wouldn't look nice if stability-oriented distributions were forced to be seen as shipping "last year's kernel". It also looks stupid to patch a kernel you know is NN months old, even though you know it's the one you need to patch for reason XYZ. If you mean bumping the major release number every N years, then you'd have people complaining when a "major" release inevitably ships only minimal improvements. I think feature-based is still the way to go, maybe there should be a regular discussion on what is "big enough" to grant a bump, done roughly every two or three years.
- coldpie 12y ago
  Yeah, I meant explicit dates in the version. The releases aren't feature-based now, and haven't been since like the 2.4 series, or maybe even earlier. They just merge whatever's ready, do a few months of testing and bugfixing, and release. The first two version numbers (3.x) are literally meaningless outside of identifying the particular set of merges that happened during the merge window. I think that'd be better represented by a date. That's a fair point that some distro shipping a 3-year-old kernel might look bad for PR purposes, even if it has patches backported.
  - tormeh 12y ago
    How about 2013.05.20__2014.02.13 for a kernel that was released in 2013 and last patched today?
    - knd775 12y ago
      It is currently 2015 ;)
      - tormeh 12y ago
        It had to happen...
- ricw 12y ago
  It would make more sense to have 15.01, i.e. YY.MM. Works perfectly fine for ubuntu and would likely not break the numbering scheme..
johngd 12y ago
Curious how/if Redhat would deal with date-based versioning. 2.6.32 was originally released ~6 years ago and for-better-for-worse their frequent security patching would make the original release date fairly irrelevant.
- BuildTheRobots 12y ago
  The problem with RHEL backporting security fixes (and Debian to a lesser extent) almost makes version numbering irrelevant too, though.
  - jgillich 12y ago
    Agreed, even more so because RedHat doesn't just backport security fixes, but also features (one example is the btrfs stuff in RHEL6, which, according to a developer, is from Linux ~3.8 IIRC).
CopperWing 12y ago
They already discussed about this few years ago, but they decided against a date-based versioning because that would have meant breaking a lot of scripts and programs doing kernel detection assuming the old scheme. [1] [1] https://lkml.org/lkml/2011/5/23/358 https://lkml.org/lkml/2011/5/23/358
- TazeTSchnitzel 12y ago
  Maybe just make the major be (year - 2000) and have the minors increment as normal?

by coldpie 12y ago

mitchell_h 12y ago

Linux people have a natural, inbuilt fear, of everything BSD related. Date based releases are evil! That's slightly a joke, but I think in reality the development model that Linus and the other maintainers have created are feature based more than timeline based. As a developer I would enjoy a date based release schedule. I don't follow HEAD closely anymore but it would be easier to keep up the general view I try to keep. BTW; In a way the distributions already do a date based release. RHEL 6. RHEL6.1, RHEL6.2, etc.

BuildTheRobots 12y ago
I've seen Linus loose it with devs in the past for breaking backwards compatibility with kernel updates; I'd suggest this also has something to do with it -possibly more so than an inbuilt fear of BSD [1]. I'm failing to find an explanation of how the RHEL numbering scheme is date based -please could you expand? [1] As a long term linux user, I have both fear and bafflement over BSD device naming and the lack of gnu options on standard utils ;)
- mitchell_h 12y ago
  The numbering scheme isn't date based, but the release schedule is. You can point at RHEL6.3 and say Released "2012-06-20"
  - BuildTheRobots 12y ago
    Not entirely sure what you mean by release schedule. I found this[1] list which lists releases and dates, but (unless I'm being thick,) it's not like they're minor-bumping every x months, it seems to be arbitrary. And if it's arbitrary, I don't see how it matters. If I'm looking up the release date for 6.3 then I may as well look up the release date for 2.6.32...
protomyth 12y ago
Which BSD is doing date based releases?
- mitchell_h 12y ago
  OpenBSD and FreeBSD
  - protomyth 12y ago
    OpenBSD releases every 6 months but does a #.# scheme incrementing the point number each release, so no date in the release number. FreeBSD has not been on a fixed schedule and doesn't use dates in their version numbers.

toyg 12y ago

If you mean having something like "2015.01.13", it wouldn't look nice if stability-oriented distributions were forced to be seen as shipping "last year's kernel". It also looks stupid to patch a kernel you know is NN months old, even though you know it's the one you need to patch for reason XYZ. If you mean bumping the major release number every N years, then you'd have people complaining when a "major" release inevitably ships only minimal improvements. I think feature-based is still the way to go, maybe there should be a regular discussion on what is "big enough" to grant a bump, done roughly every two or three years.

coldpie 12y ago
Yeah, I meant explicit dates in the version. The releases aren't feature-based now, and haven't been since like the 2.4 series, or maybe even earlier. They just merge whatever's ready, do a few months of testing and bugfixing, and release. The first two version numbers (3.x) are literally meaningless outside of identifying the particular set of merges that happened during the merge window. I think that'd be better represented by a date. That's a fair point that some distro shipping a 3-year-old kernel might look bad for PR purposes, even if it has patches backported.
- tormeh 12y ago
  How about 2013.05.20__2014.02.13 for a kernel that was released in 2013 and last patched today?
  - knd775 12y ago
    It is currently 2015 ;)
    - tormeh 12y ago
      It had to happen...
ricw 12y ago
It would make more sense to have 15.01, i.e. YY.MM. Works perfectly fine for ubuntu and would likely not break the numbering scheme..

johngd 12y ago

Curious how/if Redhat would deal with date-based versioning. 2.6.32 was originally released ~6 years ago and for-better-for-worse their frequent security patching would make the original release date fairly irrelevant.

BuildTheRobots 12y ago
The problem with RHEL backporting security fixes (and Debian to a lesser extent) almost makes version numbering irrelevant too, though.
- jgillich 12y ago
  Agreed, even more so because RedHat doesn't just backport security fixes, but also features (one example is the btrfs stuff in RHEL6, which, according to a developer, is from Linux ~3.8 IIRC).

CopperWing 12y ago

They already discussed about this few years ago, but they decided against a date-based versioning because that would have meant breaking a lot of scripts and programs doing kernel detection assuming the old scheme. [1] [1] https://lkml.org/lkml/2011/5/23/358 https://lkml.org/lkml/2011/5/23/358

TazeTSchnitzel 12y ago
Maybe just make the major be (year - 2000) and have the minors increment as normal?