If anyone happens to be hip hop-challenged enough to not get the wording of the first choice, it's a reference to the song "Baby Got Back" by Sir Mix-A-Lot (http://en.wikipedia.org/wiki/Baby_Got_Back). That made me smile. :)
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.
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.
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 ;)
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...
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.
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.
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.
Numeric sorting can still work after 985 years. Only question is whether to use 1000.01 or 3000.01. I slightly prefer former, as a final rejection of the culture-specific BC/AC split. The ascendance of the net is the beginning of the real CE. Though skipping year notation altogether for seconds (or some 10s multiple of) since the epoch would also be fun for versioning.
Any dating scheme is going to be culture-specific. The point you pick to be "year zero" is always going to be a point in time that's culturally valuable.
> The ascendance of the net is the beginning of the real CE.
That's an assertion that a marker you find culturally important (as a techie) is more meaningful to you than a marker that other people find culturally significant.
You could just as well choose the Before Present dating scheme, which defines "present" as 1 January 1950, roughly the point in time when the number of atomic explosions made radiocarbon dating obsolete (and the beginning of an astronomical epoch). But that is also culturally-specific, relative to the concerns of a certain epistemic community.
You're right, thanks. The claims in my comment require lots of qualification, are embarrassing without.
I enjoy your a[s]t[ron]omic epoch year zero idea. One could start from much further back (eg beginning of universe, earth, modern humans, writing) but those would all be specific to the culture estimating them and to what that culture valued.
> 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.
But stability-oriented distributions ARE shipping "last year's kernel", and people ARE patching a kernel that is NN months old (whether they know it or not).
Yes?
You are arguing that what people are actually doing should be kept less transparent, because if it were obvious what they were doing it would look bad?
While that might be what people want for marketting-related purposes, it kind of offends my sensibilities, it seems like lack of transparency here is not helpful for improvement to release practices, and I doubt Linus himself would like that argument very much.
> You are arguing that what people are actually doing should be kept less transparent, because if it were obvious what they were doing it would look bad?
It would be nice if all people were so logically minded, and could think rationally about pros and cons of running a battle-hardened piece of code from last year, being guided in their decisions only by the unshakable faith in the values of critical thought and Scientific Enlightenment as declined by our Engineer-in-Chief.
The truth is, we all know that the average geek, giving a choice between $software version 2012_11_20 and 2014_12_15, would almost always pick the latter. Arguments that "the 2012_11* codeline is a workhorse and runs better with our hardware!" would simply not cut it; newer software will have more bugs fixed, right? It's only natural. Of course "nobody would run 2015_02_13, it's too bleeding edge", but a couple of months should be fine, surely? ... This sort of thought is not even conscious in most seasoned geeks, but it's inevitably there. Anything older than a few months would quickly lose all significance.
A date will irrevocably reduce a piece of software to a moment in time, an idea that a release is just a timestamp on a single line going from A to B; a date-agnostic release number gives software an identity that transcends time, so that it will actually make the choice clearer: you run 2.x because you want some features and not others for your own purposes, regardless of when they were released.
Man is what it is, and despite all their protestations, engineers are just men. If you think this sort of process does not happen in our minds, or that it doesn't matter in the end, then you should try replacing a release manager with a small timestamp-checking shell script.
Ubuntu releases on specified dates and has names associated with those dates. Basically arguing that a date dilutes the value of the release seems pretty weak to me. Given that we are "engineers" who are people I think we would be able to look at a changelog of some sort and understand what a particular time stamp brings with it.
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.
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).
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]
Just adopt semver. Stop romanticizing a version number. Give big releases a flowery names if that's important to you. Leave the version number as something with specific meaning.
Not sure whether semver makes sense at the kernel level. E.g. I was under the impression that maintaining drivers outside the kernel was a fool's errand because the interface keeps changing.
Imo the change of such an interface warrants a version bump . They should not be doing it often anyway. As a result this will reset the minor version number once in a while.
This kind of comment just show ignorance. The kernel has been around for a few decades while semver has been around for what, 3 years now?
Maybe it will adopt semver at some stage. I doubt it because the API is way too complex and broad to be covered in simple x.x.x notation, think of driver updates on vendors.
This is not a fair statement. I didn't say the kernel should have been using semver 20 years ago, I said they should use it now. It exists now; it's good.
Semver isn't the one and only way of versioning stuff. Heck, it's a pretty ridiculous model for projects that do releases based on time rather than features...
Sure, my point was not that semver is the best, my point was that version numbers aren't a product name, they should be scientific. Whether it's semver or date-based, as long as it obeys rules so that people using your product can easily distinguish versions.
> version numbers aren't a product name, they should be scientific
That's your opinion. It seems there's a lot of people in the software industry with a different opinion.
I'm not saying it isn't a good thing when version numbers are meaningful. But that's not always the case and even when it's the case, you'd better check what it means for a particular project. There's no generic "scientific" rule about version numbers.
That really depends on the viewpoint. The user-space APIs are stable and the Kernel project is going great lengths to ensure that userspace is never broken (any breakage is treated as a bug).
So if you look at the userspace interface as the API semver would work against, we'd be at 1.0.1234 or something.
> If Linux used semantic versioning we'd be up to at least version 200.0 by now.
So what? 200 makes sense for software as old and consistently maintained as the Linux kernel. What is with the need of people to keep version numbers low?
Why has he chosen Google+ of all places to hold this vote?
I wanted to vote, but no, can't do that without joining Google+ again, which I am emphatically against.
Of all social media platforms to vote on, the only one more closed than Google+ would have been Facebook.
Next time can we please use something like SurveyMonkey or Doodle (might not work for this) or ANYTHING but a f#$%ing social network that requires a login?
I think it's an informal "testing the water" type poll, not a serious discussion/decision-making platform. Google+ is harder to ballot-stuff than a trivial open polling platform.
Stop being so pedantic, you already have a login, again, somebody like Linus Torvals that changed the world doesn't need to comply to your entitlements, in other words is his survey not yours.
Note: if you click on the total number of votes above the poll, you can see the results without logging in or voting. Current results with 8,509 votes.
43% (3,687) I like big versions, and I cannot lie
57% (4,822) v4.0, 'cause I get confused easily
You would prefer to wait a month for a security update rather than get it as soon as possible, is what you're saying? Even when the update process is as non-tedious as Linux's?
While this is not even kernel related, I'd like it to coincide with significant adoption of Wayland. It's more of a distro-level thing, but it is a major advance in the Linux world. So hold off on 4.0 until some desktops and distros are ready for that as a default.
69 comments
[ 3.4 ms ] story [ 132 ms ] threadThat'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.
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 ;)
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...
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.
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.
Works perfectly fine for ubuntu and would likely not break the numbering scheme..
Any dating scheme is going to be culture-specific. The point you pick to be "year zero" is always going to be a point in time that's culturally valuable.
> The ascendance of the net is the beginning of the real CE.
That's an assertion that a marker you find culturally important (as a techie) is more meaningful to you than a marker that other people find culturally significant.
You could just as well choose the Before Present dating scheme, which defines "present" as 1 January 1950, roughly the point in time when the number of atomic explosions made radiocarbon dating obsolete (and the beginning of an astronomical epoch). But that is also culturally-specific, relative to the concerns of a certain epistemic community.
I enjoy your a[s]t[ron]omic epoch year zero idea. One could start from much further back (eg beginning of universe, earth, modern humans, writing) but those would all be specific to the culture estimating them and to what that culture valued.
But stability-oriented distributions ARE shipping "last year's kernel", and people ARE patching a kernel that is NN months old (whether they know it or not).
Yes?
You are arguing that what people are actually doing should be kept less transparent, because if it were obvious what they were doing it would look bad?
While that might be what people want for marketting-related purposes, it kind of offends my sensibilities, it seems like lack of transparency here is not helpful for improvement to release practices, and I doubt Linus himself would like that argument very much.
It would be nice if all people were so logically minded, and could think rationally about pros and cons of running a battle-hardened piece of code from last year, being guided in their decisions only by the unshakable faith in the values of critical thought and Scientific Enlightenment as declined by our Engineer-in-Chief.
The truth is, we all know that the average geek, giving a choice between $software version 2012_11_20 and 2014_12_15, would almost always pick the latter. Arguments that "the 2012_11* codeline is a workhorse and runs better with our hardware!" would simply not cut it; newer software will have more bugs fixed, right? It's only natural. Of course "nobody would run 2015_02_13, it's too bleeding edge", but a couple of months should be fine, surely? ... This sort of thought is not even conscious in most seasoned geeks, but it's inevitably there. Anything older than a few months would quickly lose all significance.
A date will irrevocably reduce a piece of software to a moment in time, an idea that a release is just a timestamp on a single line going from A to B; a date-agnostic release number gives software an identity that transcends time, so that it will actually make the choice clearer: you run 2.x because you want some features and not others for your own purposes, regardless of when they were released.
Man is what it is, and despite all their protestations, engineers are just men. If you think this sort of process does not happen in our minds, or that it doesn't matter in the end, then you should try replacing a release manager with a small timestamp-checking shell script.
They are only numbers after all.
Those who always want the latest and greatest can see easier when their kernel gets "too old".
And the rest of us who run behind the curve benefits from the increased test coverage.
[1] https://lkml.org/lkml/2011/5/23/358
Maybe it will adopt semver at some stage. I doubt it because the API is way too complex and broad to be covered in simple x.x.x notation, think of driver updates on vendors.
That's irrelevant.
I doubt it because the API is way too complex and broad to be covered in simple x.x.x notation
They don't use that notation now?
That's your opinion. It seems there's a lot of people in the software industry with a different opinion.
I'm not saying it isn't a good thing when version numbers are meaningful. But that's not always the case and even when it's the case, you'd better check what it means for a particular project. There's no generic "scientific" rule about version numbers.
If Linux used semantic versioning we'd be up to at least version 200.0 by now.
So if you look at the userspace interface as the API semver would work against, we'd be at 1.0.1234 or something.
So what? 200 makes sense for software as old and consistently maintained as the Linux kernel. What is with the need of people to keep version numbers low?
I wanted to vote, but no, can't do that without joining Google+ again, which I am emphatically against.
Of all social media platforms to vote on, the only one more closed than Google+ would have been Facebook.
Next time can we please use something like SurveyMonkey or Doodle (might not work for this) or ANYTHING but a f#$%ing social network that requires a login?
Stop being so pedantic, you already have a login, again, somebody like Linus Torvals that changed the world doesn't need to comply to your entitlements, in other words is his survey not yours.
I can't believe there are so many critical security update that much often...