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.
The blog post is confusing, but the image is very clear.
5.2.0 was released.
Then 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, and 5.2.6 were released as stable updates. Pretty straightforward.
After 5.2.0 came out, normal development continued toward the upcoming 5.3.0 in Linus’s mainline tree. As bugfixes for real problems (crashes, data corruption, build breaks, security issues, etc.) were written and merged into mainline, a subset of those fixes was then backported to the 5.2.y stable branch and released as 5.2.1, 5.2.2, and so on.
In other words, there is a separate 5.2.y branch, but most of its changes are not developed there first. They are developed in mainline (the code that will eventually become 5.3.0 and beyond) and then cherry-picked back into 5.2.y as “stable” bugfixes. There is no “merge 5.2.x back into 5.3.0”; instead, stable only takes fixes that are already in mainline.
This means that any fix you see in a 5.2.y release should already be present in the mainline code that leads to 5.3.0 (or replaced by an equivalent fix there). So when you move from 5.2.6 to 5.3.0, you should not lose any of the bugfixes you were getting from the 5.2.y stable series.
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.
Me neither. Surely semver would be a lot simpler than having to explain it in a long blog post.
The blog post is confusing, but the image is very clear.
5.2.0 was released. Then 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, and 5.2.6 were released as stable updates. Pretty straightforward.
After 5.2.0 came out, normal development continued toward the upcoming 5.3.0 in Linus’s mainline tree. As bugfixes for real problems (crashes, data corruption, build breaks, security issues, etc.) were written and merged into mainline, a subset of those fixes was then backported to the 5.2.y stable branch and released as 5.2.1, 5.2.2, and so on.
In other words, there is a separate 5.2.y branch, but most of its changes are not developed there first. They are developed in mainline (the code that will eventually become 5.3.0 and beyond) and then cherry-picked back into 5.2.y as “stable” bugfixes. There is no “merge 5.2.x back into 5.3.0”; instead, stable only takes fixes that are already in mainline.
This means that any fix you see in a 5.2.y release should already be present in the mainline code that leads to 5.3.0 (or replaced by an equivalent fix there). So when you move from 5.2.6 to 5.3.0, you should not lose any of the bugfixes you were getting from the 5.2.y stable series.
Sure, but I still don’t understand why they decided against semantic versioning. That way people would be far less confused.
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.