Despite having a stable release model and cadence since December 2003, Linux
kernel version numbers seem to baffle and confuse those that run across them,
causing numerous groups to mistakenly make versioning statements that are flat
out false. So let’s go into how this all works in detail.
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
then I think that would be on like 3.77.0 or something right now. Not terrible, but honestly prefer it to be like the major upped in the new year every year. It is about 43 years old,so 43.x in 2026. Would be easier to know how old a kernel release is without looking it up.
Would be easier to know how old a kernel release is without looking it up.
I concur, but it would be much easier to make the major version the current year (as many projects do, and Linux should imo) rather than the whole project’s age at the time of a release.
If semantic versioning is:
MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes
then I think that would be on like 3.77.0 or something right now. Not terrible, but honestly prefer it to be like the major upped in the new year every year. It is about 43 years old,so 43.x in 2026. Would be easier to know how old a kernel release is without looking it up.
I concur, but it would be much easier to make the major version the current year (as many projects do, and Linux should imo) rather than the whole project’s age at the time of a release.
Linux is only 34 years old, btw.
I must have been tired when I did that math. I’d be happy with the year as well. Just don’t use the firefox/chrome model.