[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.