|
|
Subscribe / Log in / New account

Help Linus decide what to call the next kernel

[Posted February 13, 2015 by corbet]

Do you have an opinion on whether the next kernel release should be called 3.20 or 4.0? Linus is currently running a poll on Google+ to get a sense for what people would prefer. "So - continue with v3.20, because bigger numbers are sexy, or just move to v4.0 and reset the numbers to something smaller?" As of this writing, the 4.0 option appears to be winning.
to post comments

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 19:02 UTC (Fri) by marduk (subscriber, #3831) [Link] (3 responses)

How about call it Linux 10.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 19:12 UTC (Fri) by sjj (guest, #2020) [Link] (2 responses)

No, this OS goes to 11.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 22:27 UTC (Fri) by felixfix (subscriber, #242) [Link]

It's already there .... in binary.

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 1:50 UTC (Sat) by gracinet (guest, #89400) [Link]

Shall we nickname it Marshall then ?

Seriously with Internet Of Things all over the place, the idea of a Linux guitar amp is not so exotic after all, eh ?

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 19:31 UTC (Fri) by bentley (subscriber, #93468) [Link] (4 responses)

Since new kernel versions are released somewhat regularly, date-based versions might make sense (eg Ubuntu). We could have Linux 15.02, 15.04, etc. The only issue is that that exact numbering scheme would be easily confused with Ubuntu's.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 20:06 UTC (Fri) by HelloWorld (guest, #56129) [Link] (2 responses)

For this to work one would have to know in which month exactly the kernel is released, which is hard as slipping release dates are far from unheard of. Otherwise you'd either have releases with a version number that doesn't actually match the release date or you'd end up with rcs whose version number doesn't match the final release's.
That said, I'm also in favour of some new, sensible versioning scheme, the current one is just silly. fwiw, I'd simply drop the 3. part and continue counting. less' version number is 471. Who cares? One doesn't run out of natural numbers.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 21:38 UTC (Fri) by proski (subscriber, #104) [Link] (1 responses)

It should be possible to use the date of the rc1 tag. That's what good programmers do - grab the resource when you need it. Who cares if the release date doesn't match the version. The stable series would still use the same kernel version plus serial number. So, rc1 released in March 2015 would be v15.03, the corresponding released kernel released in May 2015 would still be v15.03, the stable series would be v15.03.1, v15.03.2 etc even if they are released in August 2015, January 2016 etc.

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 16:06 UTC (Sat) by jengelh (guest, #33263) [Link]

The poll gave exactly two options, specifically because the mind was already made up up to that point. Throwing in third, fourth options won't help, save the breath.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 21:13 UTC (Fri) by gvy (guest, #11981) [Link]

Valdis Kletnieks
+Brandon Price So Linux 15.2 for this month. For the second version in the same month, 15.2.1, and so on

That doesn't actually work. Look how stable kernel numbers work - 3.14.33 wasn't the 33rd release in that month, and came out after 3.15 through 3.18.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 19:49 UTC (Fri) by lafp (subscriber, #89554) [Link] (4 responses)

Linux 3.11 was "Linux for Workgroups". In the same vein, I propose calling Linux 4 "Linux4GW".

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 19:58 UTC (Fri) by utoddl (guest, #1232) [Link]

Embedded Linux for Supercomputer Phone Clusters?

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 3:05 UTC (Sat) by josh (subscriber, #17465) [Link] (2 responses)

I anticipate a creative codename for Linux 4.20.

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 6:01 UTC (Sat) by jake (editor, #205) [Link] (1 responses)

> I anticipate a creative codename for Linux 4.20.

5.0h wow man! :)

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 6:33 UTC (Sat) by josh (subscriber, #17465) [Link]

It's too bad 3.5 dropped token ring support, because someone clearly ought to get kernel 4.20 working on a tokin' ring.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 19:59 UTC (Fri) by cyperpunks (subscriber, #39406) [Link] (10 responses)

Use openssh scheme: x.9 goes to x+1.0
Too late for 3.x series, however 4.9 should followed by 5.0.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 21:31 UTC (Fri) by Beolach (guest, #77384) [Link] (7 responses)

I concur. On the poll I voted for larger numbers, but since smaller numbers seem to be winning & Linus prefers that, 4.9 -> 5.0 makes a lot more sense in my head than 3.20 or 3.21 or whatever -> 4.0.

Another possibility I thought of, is tying it to LTS versions somehow. Maybe if GregKH says 3.19 (or 3.x) will be a LTS version, then Linus' next release would be 4.0. Then when GregKH says 4.x will be LTS, Linux switches to 5.0. But I don't know how GregKH decides on LTS versions, or if the timing on his decision would work w/ Linus switching the major number...

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 22:11 UTC (Fri) by JamesErik (subscriber, #17417) [Link] (5 responses)

+1 for basing on LTS versions

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 16:05 UTC (Sat) by kreijack (guest, #43513) [Link] (4 responses)

> +1 for basing on LTS versions

I disagree. Ok for 4.0 as a LTS, but the 4.1 what would means ? I read this as "4.1 is the 4.0 plus some bugfix and *minor* changes..." but this is not true.

The whole point of the question is that *today* the major number means anything. At this point I suggest to take year/month as version numbering; something like 15.02. The LTS could be marked with a LTS suffix and a further index for the micro. So:

3.16 -> 14.08LTS
3.16.1..3.16.65 -> 14.08LTS.1 ... 14.08LTS.65
3.17 -> 14.10
3.17.1 -> 14.10.1
3.18 -> 14.12
3.18.7 -> 14.12.7
3.19 -> 15.02

Help Linus decide what to call the next kernel

Posted Feb 15, 2015 15:39 UTC (Sun) by fandingo (guest, #67019) [Link] (3 responses)

> I disagree. Ok for 4.0 as a LTS, but the 4.1 what would means ?

That's not what the recommendation is. The major version number rolls over *after* the LTS release. If the current release were to become LTS, then LTS is 3.19. For subsequent bugfixes to that LTS, they could either do 3.20, 3.21, etc., or 3.19.1, 3.19.2, etc.

The next kernel release would be 4.0. Then, at some later point, there's a 4.15 (or whatever) that becomes LTS, and the kernel next regular release becomes 5.0.

The *last* minor release number for a major version is the LTS, not the first minor release number for a major version.

I don't like the idea, though, probably because I don't use LTS kernels. I'd rather do it date based. I would rather avoid the Y2K problem and use YYYY.MM, though.

Help Linus decide what to call the next kernel

Posted Feb 16, 2015 9:47 UTC (Mon) by dany (guest, #18902) [Link]

this is best recommendation in whole thread, numbering based on LTS release, very clever and simple

Help Linus decide what to call the next kernel

Posted Feb 16, 2015 17:43 UTC (Mon) by Kamilion (guest, #42576) [Link] (1 responses)

Rolling over to a higher Major version on the heels of LTS kernels somewhere around the fingers-and-toes mark does indeed sound like a pretty good plan. It's been around four years since the last major bump; at this rate, we'd be at linux 10.0.0 around 2043, and 20.0.0 by 2083. That's a pretty reasonable progression rate that could outlast Linus's Head In A Jar, if Futurama's anything to go by.

Help Linus decide what to call the next kernel

Posted Feb 17, 2015 14:51 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

But then Linus won't have any fingers *or* toes to count on and we'll start using just a major version number ;) .

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 0:43 UTC (Sat) by ncm (guest, #165) [Link]

+1 for objective branching criteria of any sort. This one is good.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 23:16 UTC (Fri) by xxiao (guest, #9631) [Link]

Since we're having two releases each year roughly, over time this could become 35.9, 36.1, not very balanced soon

Help Linus decide what to call the next kernel

Posted Feb 17, 2015 6:14 UTC (Tue) by kragil (guest, #34373) [Link]

I think that is Linus plan, it will just take some time to get there.

I see a pattern, a migration of sorts:
.39 -» 3.0
.19 -» 4.0
.9 -» 5.0

This is where I think the pattern will stop and stay.

Just guessing though, my mindreading is off today.

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 22:53 UTC (Fri) by dfsmith (guest, #20302) [Link] (2 responses)

With the hot kernel patching added, we may be running 4.0 forever....

Help Linus decide what to call the next kernel

Posted Feb 13, 2015 23:10 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

Hot kernel patching only works for pretty trivial patches. If you think that you are going to be able to 'never reboot again, just patch everything on the fly', you are dreaming or drinking the kool-aid

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 0:45 UTC (Sat) by ncm (guest, #165) [Link]

-1 for missing the joke.

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 0:41 UTC (Sat) by pabs (subscriber, #43278) [Link] (6 responses)

How do we help Linus decide if we don't have a Google+ account? Should we email Linus about this? and maybe remind him about this article in the process :)

http://mako.cc/writing/hill-free_tools.html

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 0:54 UTC (Sat) by scientes (guest, #83068) [Link]

Does that matter so much with a deliberately bike-shed debate?

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 12:04 UTC (Sat) by zdzichu (subscriber, #17118) [Link]

Then you don't help. Don't bother with email, it will only be spam; Linus has chosen communication channel suiting him, don't be mean by trying to force your choice.

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 12:36 UTC (Sat) by juliank (guest, #45896) [Link]

Well, if you want to be yelled at, do it

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 20:35 UTC (Sat) by Seegras (guest, #20463) [Link]

So what? It's not like this is a vote. It's more like a poll, and if the sample is large enough, which might be the case with google+, that's good enough.

Help pushing alternatives to G+, Facebook, Twitter

Posted Feb 15, 2015 16:23 UTC (Sun) by debacle (subscriber, #7114) [Link] (1 responses)

Paul, I believe that Linus is very well aware of the fact, that G+ is a non-free walled garden. He chose to use this medium for most of his communication anyway, so there is not much we can do about it. In general, it is a very sad tendency to see many free software development chosing non-free services, when free alternatives are available. OTOH, we all were upset when Linus decided to use Bitkeeper - and finally came up with git! Maybe at some point Linus will present the ultimate G+ killer?

(For the time being, I personally decided not to use G+, Facebook, Twitter, but Pump.io and - soon - MediaGoblin.)

Help pushing alternatives to G+, Facebook, Twitter

Posted Feb 15, 2015 23:22 UTC (Sun) by cesarb (subscriber, #6266) [Link]

> Maybe at some point Linus will present the ultimate G+ killer?

I don't think Linus is going to be kicked out of Google Plus.

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 6:31 UTC (Sat) by csamuel (✭ supporter ✭, #2624) [Link] (3 responses)

If we skip straight to 4 we miss the opportunity to emulate TeX.

Linux 3.14159 FTW..

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 6:36 UTC (Sat) by josh (subscriber, #17465) [Link] (2 responses)

https://lwn.net/Articles/607350/

Help Linus decide what to call the next kernel

Posted Feb 15, 2015 1:40 UTC (Sun) by gerdesj (subscriber, #5446) [Link] (1 responses)

That was for 3.14.15 but I recall pi=3.1415926536 so 3.14.16 would be more appropriate 8)

Help Linus decide what to call the next kernel

Posted Feb 20, 2015 11:03 UTC (Fri) by domo (guest, #14031) [Link]

but now next version can be 3.14.15.9

Change rules on major version bumps!

Posted Feb 14, 2015 8:34 UTC (Sat) by dambacher (subscriber, #1710) [Link]

While i like the way of distinguishing aged kernels by high numbers, bumping on LTS is ok, too.
Didn't we change the numbering rules on every major version bump?

Help Linus decide what to call the next kernel

Posted Feb 14, 2015 10:04 UTC (Sat) by toyotabedzrock (guest, #88005) [Link]

I think a switch to 4.0 would be great when live patching is fleshed out and ready for wider use.

It seems like the kind of new great breaking feature maybe along with btrfs to actually have make it worth while.

It would even be an awesome PR score against Windows annoying updates.

You could dumb depreciated code and continue to update the 4.x and 3.x series.

Meanwhile the backlight on my intel desktop and laptop still doesn't work....

Posted Feb 14, 2015 17:18 UTC (Sat) by leoc (guest, #39773) [Link] (1 responses)

So let's paint the shed red... i mean number the kernel 4!

Meanwhile the backlight on my intel desktop and laptop still doesn't work....

Posted Feb 14, 2015 22:09 UTC (Sat) by flussence (guest, #85566) [Link]

There's an idea - let's drop the archaic base-10 versioning scheme and use a modern Web 2.0 versioning scheme based around html4 named colours. Backwards compatibility is easy, we can sort them by their HSV numbers. Linux Red, Linux Beige, Linux DarkSalmon...

Version limitations

Posted Feb 14, 2015 19:14 UTC (Sat) by cesarb (subscriber, #6266) [Link]

To help people decide...

* Each of the three components of the version number is an 8-bit number (see include/linux/version.h).
* Any change of the major version number will need a corresponding change to the UNAME26 code (see kernel/sys.h).

Help Linus decide what to call the next kernel

Posted Feb 15, 2015 4:35 UTC (Sun) by glikely (subscriber, #39601) [Link] (1 responses)

Wow. 500 comments on the poll thread... And the bikeshed shall be blue.

Help Linus decide what to call the next kernel

Posted Feb 16, 2015 19:56 UTC (Mon) by bronson (subscriber, #4806) [Link]

This way a lot of people can feel good about having contributed to the kernel.

Help Linus decide what to call the next kernel

Posted Feb 16, 2015 21:31 UTC (Mon) by malor (guest, #2973) [Link]

I'm in this camp: call it what you want, as long as the new number is bigger than the old number, and we'll make do. Somehow.

Help Linus decide what to call the next kernel

Posted Feb 18, 2015 0:39 UTC (Wed) by zblaxell (subscriber, #26385) [Link] (1 responses)

Last time this happened I had to work around a (steaming) pile of software that, for reasons I don't care to understand, insisted that Linux kernel versions consisted of two dotted decimal numbers following the string "2.6." and would raise a fatal error if uname() said otherwise.

I can't really say I'm fond of innovations in this particular part of the kernel.

Help Linus decide what to call the next kernel

Posted Feb 18, 2015 0:45 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, you can always use uname26 personality: https://lwn.net/Articles/451168/


Copyright © 2015, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds