[uniformlyrandom]

I actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.

[CaliforniaKarl]

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.

[1stranger]

I assume they were referring to calendar based naming a la Ubuntu.

https://calver.org

[michaelmrose]

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.

[zanny]

The version.patch notation is still meaningful to Linux because each version increment means new features and support. If the latest is version 50 and you are on 48 you should be suspicious if that unsupported PCI device works on that newer release.

Its just the major version that is always redundant because Linux never breaks userspace compatibility.

But of all software projects the Linux kernel is definitely not a poster child for having a reasonable methodology to versioning. Just some choice released kernel version names: 0.95, pre2.0, 2.2 and 2.4 but no 2.1 or 2.3, 2.6 lasted 8 years, 3.19 - 4.0 because Linus felt like it, and 4.20 -> 5.0 because Linus felt like it.

The only consistent number has been patch releases.

[zanny]

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.

[azernik]

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.

[jplayer01]

Huh? Ubuntu does the date as version and they do patch fixes and what not.