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.

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.

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!).

Did not we just see a fight last year, between, I think, AMD and Linux, where AMD, instead of the common practice to drop a blob and be done with it, tried to actually upstream some drivers, but they were not up to Linux's coding standards, so got rejected.

I am not saying AMD is in right here. Maybe nobody is, given the current state of affairs. But it is end users who are suffering from the conflict of interest between Linux community, who doesn't want to maintain cheaply written code, and hardware companies, who can't make great open source drivers for the same money they can make an OK-ishly made closed source blob, that only supports 2yo LTS.

That decision, that I can't have the latest Linux and 5yo drivers that work is simply bad for me as a consumer. Heck, if Linux had stable driver API, somebody could easily go and fix that just slightly buggy AMD driver to be compatible with the latest kernel without much fuss, and without the need to upstream it. And I could use my laptop with the supported kernel again.

I think stable driver API for Linux would do a great good to billions of people. Would let them not to spend money every 3 years on a new phone, and let Microsoft to let Windows 10 go, finally bringing proper privacy to the common folk.

The binary compatibility came, and package maintainers rejoiced. Finally, they did not have to make a package for each distribution separately, and could get to actually improving the contents of the packages themselves.

The docker came, and the ops and admins rejoiced. Finally, they are able to build a giant web app, and deploy it anywhere with that tiny container daemon, even on Windows. So they can actually focus on improving their web apps instead of wasting Saturday nights tweaking configurations.

When the stable driver API comes, the driver developers will rejoice.

So small business needs it even more. Don't you think that is a good reason on its own?