Linus Torvalds' poll about “big versions” in kernel releases
plus.google.com
plus.google.com
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'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.
43% (3,687) I like big versions, and I cannot lie
57% (4,822) v4.0, 'cause I get confused easily 43% (4,627) I like big versions, and I cannot lie
57% (6,029) v4.0, 'cause I get confused easilyI can't believe there are so many critical security update that much often...
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.