

Linus Torvalds' poll about “big versions” in kernel releases - sWski
https://plus.google.com/+LinusTorvalds/posts/jmtzzLiiejc

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

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

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

~~~
toyg
_> 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.

~~~
4ydx
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.

They are only numbers after all.

------
unwind
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](http://en.wikipedia.org/wiki/Baby_Got_Back)).
That made me smile. :)

------
3JPLW
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

~~~
andruby
At 10,656 votes the ratio is still the same:

    
    
      43% (4,627) I like big versions, and I cannot lie
      57% (6,029) v4.0, 'cause I get confused easily

------
kasabali
This is one big bikeshedding.

~~~
nhaehnle
Absolutely. The best comment among the first few pages in that thread is this:
_" Really depends how many interviews you feel like doing :)﻿"_

------
elfgoh
I believe that the kernel should only be upgraded to version 4 after we hit
3.142

------
chli
I would suggest incrementing the major of major.minor.patch everytime a
longterm release is selected.

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

~~~
stonogo
I don't advocate having the tail deliberately wag the dog.

~~~
phkahler
I agree, but people seem to want to tie the 4.0 bump to something kind of big.

------
jokoon
I never understand why linux distributions download updates so often. I'd
prefer something monthly at the most.

I can't believe there are so many critical security update that much often...

~~~
thirsteh
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?

~~~
jokoon
How can there be so many security updates though ?

~~~
thirsteh
Every platform that receives any attention is like that.

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

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

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

------
kogepathic
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?

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

