This will also be an LTS (Long-Term Support) release.
Really good podcast on why this is an exciting release: https://youtu.be/6J3Ym0XkZDw
Is there something I could read instead of listening to an hour plus long podcast?
eBPF powered custom schedulers aka SCHED_EXT and the preempt RT stuff sound really nice.
So why do minor releases get major bumps, and major releases line this only minor bumps? Even kids on the playground get more consistency.
A new major release of the Linux kernel happens every ~8 weeks. There are usually 7 or 8 release candidates (-rc1, rc2, etc) released on successive Sundays during that period, followed by a release of the major version. That's the workflow the Linux kernel has used for years.
There's no minor and major. All releases are equivalent but the first number is bumper when the second becomes large enough, which happens every 2-3 years.
In fairness, that is a weird versioning scheme, and I really do wish that Linux either switched to full semver (in which case it'd be version 2.9000.0 or so by now) or just drop the leading digit and go full build number kinda like NT does. But as cousin comments note, not my project not my call:)
What for? Every kernel release is equal as far as maintainers are concerned, the list of features that go in depends on what is ready in time. They would have to change release processes significantly to accommodate "major versions", and I don't think they would want to do that.
Also, the kernel doesn't really have an external kernel API, the user API is supposed to be 100% stable, and its internal kAPI is nobody else's business, so there's one less reason for semver.
Why then confuse users with the first dot? The second dot having a meaning makes it even more confusing. Just drop the first dot like Chrome and Firefox did.
As the comment above stated - so that the numbers don't grow too large
I like qemu's version scheme were the major version increases every year (since version 4.0). So x.1 the first release in a year and you can see from a quick glance how "old" a version is.
I don't mind date-based versions, though if you're going to do that I feel like it'd be easier to go all the way? I can't tell how old qemu 4.0 is, but even without knowing details I would feel pretty confident in roughly when a hypothetical qemu-2024.1 had been released.
I would think most if not all of the enterprise distros would object as generally they lock their kernel versions for the duration of a "release" lifecycle and backport security fixes from newer kernels to the version they chose.
They wouldn't want users thinking they were still using a "2024" kernel in 2032, for example, when they have 10+ years of support to provide.