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