“The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0”
I laughed out loud.
3.19 -> 4.0 and 4.20 -> 5.0 just because.
From the OP email:
| So go wild. Make up your own reason for why it's 5.0.
> I ran out of fingers and toes to count on
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.
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.
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
But for software deeper in solutions, fast version changes appear confusing. I like Apache, nginx with very small bumps. Most newer JS frameworks live fast and die quick. It's also very confusing for developers to decide to jump to newer versions.
Expecting 11.20 version around 2037.
Why don't they get rid of old drivers (say, prior to 2000)?
It would make the kernel slimmer for sure. They could made optional and one has to self compile the kernel to enable them
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!).
A PM's eyes will glaze over when you talk 4.22 V 4.16, but you mention v22 versus v22 and then they 'get it'.
That's why a Chrome style versioning has value.
Also, by any reasonable definition, there is no meaningful difference between 4.20 or 420. You just put a period in there. The major number has no real significance.
It works great for servers, I can give it that. There it mostly runs on a very narrow set of hardware, or just VMs. It is stable and performant, and customizable.
But not on consumer devices. I'd like to use it eventually, but the state of driver support is still abysmal. Android phones lose support after a couple of years, and on desktop/laptops there are numerous problems too. I think that situation is caused by the lack of stable driver API.
Now that's what I'll be looking forward to for 6.0.
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?
