Linux 5.0-rc1

I can't help myself. I need to know why 5.0. Is there a reason, even a pointless one? Or is it truly a "just because" moment?

OK so Linus, like most, has 10 fingers and 10 toes: totaling 20.. Yet 4.21 was already assigned. What was the last thing he counted on? Guesses below.

I mean, that's the way it's been forever. IIRC, the release for 3.0 had the same type of message with it. There was no big breaking change, it just felt like it was time to bump the big number.

The kernel versioning (as of 3.0) has always been arbitrary. Go wild.

Coming up with a response to this one was harder than I expected. The calendar-based release cycle you describe is pretty different from what is practiced today.

Although, if you change the time scales, maybe not so much: Kernels are released on a fairly-predictable cadence now, and patches come in (to the mailing list and maintainer trees) almost constantly. So, if this is as simple as extending timescales, that leads down to an impossible debate: What changes count as minor/major/patches? For example, some would say that adding a driver is just a patch (as it doesn't change other parts of the kernel); some would say that it is major (because it adds new functionality).

There's also the human element: If someone has something to contribute, they'll want discussion to start on it sooner rather than later. Also, rolling lots of major changes into a big release may make it hard to tease out bugs—and performance regressions—as the just-released major version makes its way down to individual distributions.

So in this case, I think the best think for your needs would be to ignore upstream kernels, and instead rely on a distro kernel: Pick whichever distro you think does kernels the best, and which uses a time-based release schedule, and use their kernel.

Or, get an LWN subscription, and keep an eye out for their regular "What's new in this kernel" articles.

That's not how kernel development actually works. There's a set of supported releases that continue getting fixes over time - e.g. 4.20 will keep on getting patch fixes for a while. Better to have nothing referring to a date than some digits referring to dates and some not.

It seems likely that the people that have been doing this for decades have a reason for the current methodology.

Generally how far exactly you are behind mainstream is useless information it produces exactly zero actionable intelligence. For most people in fact no amount of information would be actionable because mostly what they ought to do is run whatever their distribution comes with. For those who do indeed need more info. For example X.y supports their hardware better or at all. In fact what they need to know in that case is what version will provide a better experience and why. Knowing how far behind they are would be pointless. Knowing this in fact will lead at least some to upgrade pointlessly and potentially hit exciting new bugs/incompatibilities that their distro hasn't tested against. As an example I note that zfs on linux now supports a max of kernel 4.19. It might in theory work with 4.20 but it might not. Joe user notices that 4.20 is out. His distro ships with 4.19 he decides to upgrade and suddenly he can no longer actually mount his root filesystem with the new kernel and he has managed to remove 4.19. Another annoying example we might suppose that the proprietary driver package he uses to talk to his gpu doesn't build against the newest kernel and he boots no further than a text console when booting.

Even if the kernel doesn't break userspace it doesn't mean that stuff doesn't ever break.

What you are suggesting is that release cadence be optimized to give more useless info to laymen to help them make worse decisions.

Besides what others have said kernel releases aren't special. They are just quarterly. There would be no "big" release each year because any arbitrary release can be "big" or not. Nobody is going to keep major functionality out of the kernel just because they want to wait for a bigger number to go up.

The worst part is its arbitrary. I don't get why Linus is so bent on keeping a three step version number when the first digit has been meaningless since 1996 (or maybe 2011 if you want to be pedantic and call the version change from 2.6.x to 3.x a major revision). For the largest free software project in the world it sure doesn't do much to advertise good practices when informing your user of relative newness of kernels.

Version 12.0 will be out shortly after, around 1970.

You can already disable building whatever drivers you don’t need when you make your kernel config.

Why are you building modules you don't use?

The kernel seems to be the most half understood part of Linux. Not picking on you specifically, it's actually super common to think:

- More drivers means slower build times

- To add a driver you need to rebuild a kernel

Both of which are wrong and have been wrong for a decade (nearly two!).

Memories!

Is it really a 'dilemma' though? Basically, a project can set the version numbers how they want. They don't need to justify the change. So long as they and others can refer to each release by a simple and easily identifiable number or moniker, it really makes no difference if it's 5.0 or 4.22. In the end, the Linux kernel is such a big project that there's really no reason to single out any single or a set of changes as significant enough to warrant a version number bump; it's all arbitrary to start with.

At this rate we would be in triple digit numbers before long.

I don’t know if you realize it, but your complaint is “hardware vendors change things too frequently”. Kernel hackers don’t make up the need to do extra work for hardware support just for kicks. Yes, the hits everyone: Windows loses support for old hardware much faster than it used to. Even the closed-ecosystem of OSX/macosx/macOS leaves hardware behind these days. Mobile phone hardware changes so frequently that you can’t even be sure that the same make & model of handset will use the same hardware. In many ways, it’s both a sign of progress and the baseline cost of doing business.

Why should vendors care? Even Qualcomm outright admitted that they prefer to "ship it and drop it" rather than keep supporting old devices.