LWN: Comments on "Seven new stable kernels"

Seven new stable kernels

mathstuf — Fri, 12 Jun 2020 15:42:41 +0000

> See how confusing???? Numbers are better trackers than names.

I feel like you missed the "/s" in my original statement :) .

Seven new stable kernels

unixbhaskar — Fri, 12 Jun 2020 13:48:53 +0000

In fact, this name spurred out of Linus's diving experience...undersea ...the explanation I gave above was the previous kernel name.

See how confusing???? Numbers are better trackers than names.

Seven new stable kernels

unixbhaskar — Fri, 12 Jun 2020 13:46:19 +0000

No, wait...all the kernel release has a name too ...please check the top-level Makefile for that entry.

Present kernel it is called: Kleptomaniac Octopus :) because Linus was encountered a squirrel running in front of his car once!

Development models and release numbers

corbet — Fri, 12 Jun 2020 13:07:58 +0000

The odd/even practice lasted through 2.6, which was a "debacle" in that it took far longer than anybody wanted to be ready for release. A two-year "feature freeze" was not fun for anybody involved.

At the 2004 kernel summit the decision was made to move away from that model and make every release a stable, production-ready release. It took a while to figure it all out, and the arrival of Git during the 2.6.12 cycle helped a lot; by the late teens the new model was well entrenched and nobody was looking back.

The decision to go to 3.0 was made by Linus after 2.6.39; it just seemed like time for a change. That numbering change didn't really mean anything beyond that.

Seven new stable kernels

mfuzzey — Fri, 12 Jun 2020 08:03:10 +0000

> Of course, the rate of change now makes that difficult.

I don't think it's *just* due to the rate of change but due to the huge scope of Linux today, from fairly small embedded devices to supercomputers.

What is a major feature for one use case may well be irrelevant for another.

And, by policy, there are no user space breaking ABI changes so it doesn't make sense to reflect that in the version number as some software does.

Seven new stable kernels

welinder — Fri, 12 Jun 2020 01:28:11 +0000

How many silly names do you expect Linus to come up with?

But, yes, we used to have releases with names like "Greased Weasel".

Seven new stable kernels

zlynx — Fri, 12 Jun 2020 00:20:21 +0000

During Linux 2, odd numbers were development versions.

As I remember it, after the 2.6 debacle, the Linux maintainers decided to go to 3.0 and a different development model.

Seven new stable kernels

jmclnx — Fri, 12 Jun 2020 00:06:24 +0000

20+ years ago, releases with odd 'minor' number(s) were considered stable, even numbers were for test. Or maybe the other way around, I forgot.

Then you had the major numbers, I think 1 --> 2 had to do with elf and shared libs (I forgot though). Somewhere in the 2.x series it was decided release numbers had no meaning.

Seven new stable kernels

mathstuf — Thu, 11 Jun 2020 18:09:38 +0000

You could always use the release names instead. /s

The thing is that with such a large project, every release is going to have big changes for someone. Sure, I may not care about a release or two in a row, but that doesn't mean they didn't warrant some special version number bump anyways.

The two component version helps to keep the numbers low though (the patch number will always creep up no matter what anyone does). Even Chrome and Firefox are in the realm where the numbers are just comparable and individual releases are just another package to update.

Seven new stable kernels

BirAdam — Thu, 11 Jun 2020 18:03:48 +0000

Obviously, I cannot encompass all of the major, minor and editorial changes and numbers and such, but here's a few

2.0: Linux included all components to configure the kernel before compiling it for specific hardware targets

Between 2.0 and 2.6 there was quite a bit of churn with new tech being added

2.6: Alsa and SELinux, with changes from previous versions, broke quite a bit of compatibility with prior releases, emphasis on stable versions started

3.0: Abandonment of using large changes to bump major and minor version numbers

Now it's all somewhat arbitrary. I am not really sure why we even do x.x.x anymore. Why not just do x.x where the second x is just number of patchsets or something? We could hit version over 9k within a few years! Sarcasm aside, it was just nice to have meaning. It doesn't actually matter or anything.

Seven new stable kernels

zlynx — Thu, 11 Jun 2020 17:15:03 +0000

When did the version numbers ever mean anything? Are you thinking about the "big changes" from ipfw to ipchains to iptables? Or the "big kernel lock?" Or how everyone ran 2.5 for three years (I might exaggerate) because no one would stop adding things "for 2.6?"

Seven new stable kernels

BirAdam — Thu, 11 Jun 2020 16:17:05 +0000

I know that it's stupid, but part of me still really dislikes the arbitrary nature of kernel versions. I miss the way major and minor version numbers carried some meaning in the past. Of course, the rate of change now makes that difficult.