Growing major version

Posted Feb 13, 2026 15:55 UTC (Fri) by alx.manpages (subscriber, #145117)
Parent article: The first half of the 7.0 merge window

<http://www.kroah.com/log/blog/2025/12/09/linux-kernel-ver...>

> The minor number is incremented by Linus every release that he makes, while the major number is only incremented every few years when the minor number gets too large for people.

I don't think it's very smart to raise the major number to avoid large minor version numbers.

Eventually, we'll have a large major version number, and there's nothing that could fix that.
Once major version reaches 20, what to do?

to post comments

Growing major version

Posted Feb 13, 2026 16:04 UTC (Fri) by corbet (editor, #1) [Link] (18 responses)

At current rates, the 19.19 kernel release can be expected sometime around 2069 or so. I suspect that Linus doesn't feel the need to plan around that milestone for a little while yet.

Growing major version

Posted Feb 13, 2026 16:07 UTC (Fri) by alx.manpages (subscriber, #145117) [Link]

Yup; that might be a problem. I expect to live past that date. :)

Growing major version

Posted Feb 13, 2026 16:09 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (3 responses)

FWIW, I've decided to settle the man-pages project at major version 6 for as long as I'm the lead maintainer. Once someone else takes care of it, it would grow to 7. That would happen less often. And then, major version is somewhat meaningful.

Growing major version

Posted Feb 17, 2026 23:30 UTC (Tue) by aphedges (subscriber, #171718) [Link] (2 responses)

Given how close the man-pages version is to the kernel version, I assumed the versioning was tied together. Is them both being 6.1x just a coincidence?

Growing major version

Posted Feb 17, 2026 23:36 UTC (Tue) by alx.manpages (subscriber, #145117) [Link] (1 responses)

They have been tied in the past.

When Michael was the lead maintainer, he followed the kernel version closely (weeks or a month).

I have been following it too, more or less, but not so closely. I wasn't happy by the fact that the project also documents glibc, but the versioning and name seems to imply that it only cares about the kernel. I think decoupling the versioning would be positive.

And after all, the version of the manual pages isn't very meaningful. We sometimes document stuff from the next kernel release, before it's even released.

The rule of thumb should be: always take the latest version of the manual pages. We never remove information (with very few exceptions). And being documentation, you don't risk regressions (or they are less dangerous than software regressions).

Growing major version

Posted Feb 17, 2026 23:40 UTC (Tue) by aphedges (subscriber, #171718) [Link]

Good to know. Thanks for clarifying!

Growing major version

Posted Feb 13, 2026 17:14 UTC (Fri) by daroc (editor, #160859) [Link] (12 responses)

Personally, I think that when that happens we should add a new major number in front, go back to 1.0.0.0 ... It wouldn't be any worse than Windows's numbering scheme.

Growing major version

Posted Feb 13, 2026 17:47 UTC (Fri) by mb (subscriber, #50428) [Link] (10 responses)

I don't really get why the numbers are separated by dots, if there's no meaning to the major/minor parts.
Why not stop this nonsense and just count a number up (like systemd)?
The individual digits would grow *slower* than with the current scheme where the two digit minor counts to 20 instead of 99.

Just release the next kernel as 7, then 8, then 9, etc and leave the dotted parts to cases where it actually makes any sense (e.g. stable).

Growing major version

Posted Feb 13, 2026 20:22 UTC (Fri) by rschroev (subscriber, #4164) [Link] (9 responses)

I'm in favor of date-based version numbers. E.g. <year>.<month>.<sequencenumber>. Makes it clear that there's no meaning to the major/minor parts other than when the kernel was released. It has the benefit that you can always immediately see how old a kernel is. The numbers will grow quite big, especially if you use 4 digits for the year, but I don't really see that as a problem when the numbers have meaning.

Growing major version

Posted Feb 13, 2026 21:13 UTC (Fri) by mb (subscriber, #50428) [Link] (8 responses)

The problem with a date based versioning is that you either have to commit to a specific date before the release, or you can't reference to a future version number before the release.
I'm not a fan of that.
I like the extremes: single number increments or semantic versioning. In-between is nonsense.

>The numbers will grow quite big, especially if you use 4 digits for the year, but I don't really see that as a problem when the numbers have meaning.

Yes, that's not a problem.

Growing major version

Posted Feb 13, 2026 22:51 UTC (Fri) by NHO (subscriber, #104320) [Link] (5 responses)

C2y begs to differ.
So, Linux 2036.0a will become 2036.01.001

Growing major version

Posted Feb 13, 2026 23:18 UTC (Fri) by mb (subscriber, #50428) [Link] (4 responses)

That I don't understand your post proves my point.

Growing major version

Posted Feb 13, 2026 23:49 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (3 responses)

ISO C uses x as a placeholder for the year of the release before the actual release. So, when ISO C23 was being developed, it was called C2x. Now that we're developing the next revision, it's called C2y, and it will eventually be C28 or C29. It wouldn't be too bad if it ends up being C30; we might just rename the temporary name to C3x if we reach 2030 without a release.

Growing major version

Posted Feb 14, 2026 0:30 UTC (Sat) by mb (subscriber, #50428) [Link]

Yeah. This is nonsense.
You end up with different version names referring to the same thing, historically.

Growing major version

Posted Feb 14, 2026 0:51 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

I suspect the main reason that works for C is that there's only one significant release per decade, so most people only need to remember the first digit and don't care about the placeholder. Probably won't scale well to something with a release every two months.

(I think it's pretty confusing even for C++ with three releases per decade, where C++0x = C++11, C++1y = C++14, C++1z = C++17. Apparently they've now committed to a strict 3-year release cycle so the dates are predictable and shouldn't need placeholders, but GCC/Clang still refer to C++2a and C++2c anyway.)

Growing major version

Posted Feb 15, 2026 1:55 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

GCC and Clang do this (AFAIK) to differentiate "C++23 in progress" from "C++23 as standardized" in the run up to C++23 actually being completed.

Growing major version

Posted Feb 14, 2026 13:24 UTC (Sat) by iabervon (subscriber, #722) [Link]

If you've got a very regular cycle like the kernel does, you can use the date when the cycle starts and get versions that are just as good as using the end of the cycle (particularly if it's only the year that's date-based). Of course, this all depends on a process where changes aren't assigned to a release until they're ready to release, with every time period seeing enough changes getting to that point to make the releases worthwhile, which is why I don't think it's a good system for the vast majority of projects.

Growing major version

Posted Feb 15, 2026 2:00 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Even with incremental numbers, you may run into the issue where you need a major bump rather than a minor. Depending on the maintenance guarantees, this may mean the current major version is "undead".

What we've ended up doing is that the release branch is x.y.z where "z" is "small". But the main development branch pushes "z" way above any actual patch release number by using the integer formed by YYYYMMDD. This is then bumped nightly. So while, say, 5.3.3 is the "latest release", development is at 5.3.20260214. Below any future release, but also way higher than any conceivable incremented patch number. Then if you end up saying "yep, 6.0 is coming" then walking it back to "whoops, the big feature missed the schedule, back to 5.4", you're still monotonic.

Growing major version

Posted Feb 13, 2026 19:38 UTC (Fri) by alx.manpages (subscriber, #145117) [Link]

I expect that would break the world.

Growing major version

Posted Feb 13, 2026 20:10 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (1 responses)

> Eventually, we'll have a large major version number, and there's nothing that could fix that

That is true, but the major version numbers change much less often. So, it is not really that hard to keep track of them. And I can keep track of recent minor versions but I agree with Linus that they all start to run together after a while.

Linux kernel version 6 was released about three years ago with version 5 about three years before that. Even if it were 156 currently and 155 three years ago, I think I could tell you the current major version number of Linux and, if you gave me a previous one, I would have a sense of how old it was. I would also have a pretty good idea of the major features that appeared in each one.

Without looking it up, I can say that Linux kernel 5 brought the introduction of Apple Silicon, io_uring, and exFAT. Apple Silicon then matured very nicely in Linux kernel 6 which aligns with the experimental period for "Rust in the Linux kernel". The major new architecture in kernel 6 has been RISC-V which is maturing nicely but, like Rust, will probably hit its stride in kernel 7. Kernel 6 also contained the bcachefs saga and the long-awaited real-time merge. Kernel 6 aligns with when most people started to trust btrfs (I still don't). We do not even have 7 and it already feels like it will be the release where both Rust and RISC-V go mainstream. Maybe bcachefs will come back. If not, perhaps a competitor. In short, the major version numbers seem meaningful in terms of marking different eras of kernel evolution.

I can tell you that "Docker containers" appeared in the kernel 4 timeframe but that you really need at least kernel 5 to run Docker today.

Contrast that to the situation where we had 2.6 forever and there was 2.6.38.8 and 2.6.25.20 three years before that (had to look that up just now). Without checking the date, could you have told me in rough terms how old the latter was or what had changed since then? Not me.

And kernel 2.4 goes all the way back to the Windows XP days. It feels like the beginning of 2.4 and the end of 2.6 is half the history of Linux.

The current system works pretty well in practice.

Growing major version

Posted Feb 13, 2026 20:29 UTC (Fri) by alx.manpages (subscriber, #145117) [Link]

Sounds reasonable. Thanks!

Growing major version

Posted Feb 13, 2026 20:24 UTC (Fri) by joib (subscriber, #8541) [Link] (1 responses)

Firefox, for instance, seems to be at version 147 at the moment. I don't lose sleep over it, so I don't see a problem with kernel 20.20 either.

If we're worried about too long version strings, one could display them as hex. :)

Growing major version

Posted Feb 13, 2026 20:29 UTC (Fri) by Wol (subscriber, #4433) [Link]

> so I don't see a problem with kernel 20.20 either.

If we have perfect vision, we'll see it :-)

Actually, when we get that far, we might decide to roll the major version every time the minor catches up. That'll slow the rise ...

Cheers,
Wol

Growing major version

Posted Feb 14, 2026 1:53 UTC (Sat) by hallyn (subscriber, #22558) [Link] (5 responses)

Lol - forget that. Imagine how many maintainer scripts and update programs will break when we switch from 9.19 to 10.0, because 9 > 1 :)

Growing major version

Posted Feb 15, 2026 2:03 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (4 responses)

Likely few as anything doing that already has problems with 6.9 > 6.10 already.

Growing major version

Posted Feb 15, 2026 2:55 UTC (Sun) by hallyn (subscriber, #22558) [Link] (3 responses)

So you don't think that https://man7.org/linux/man-pages/man2/personality.2.html will need an extension for UNAME919 alongside UNAME26? I admire, but do not share, your optimism :)

Growing major version

Posted Feb 16, 2026 2:01 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

What is the behavior today of UNAME26? It seems to ignore the major version. Is 4.1 reported the same as 3.1? The docs seem to indicate that it should…

Growing major version

Posted Feb 16, 2026 7:25 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

The comment at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/... says:

/*
* Work around broken programs that cannot handle "Linux 3.0".
* Instead we map 3.x to 2.6.40+x, so e.g. 3.0 would be 2.6.40
* And we map 4.x and later versions to 2.6.60+x, so 4.0/5.0/6.0/... would be
* 2.6.60.
*/

You can check if you distro does not patch it more with `setarch --uname-2.6 uname -r`. For me, `6.18.9-200.fc43.x86_64` gets mapped to `2.6.78-200.fc43.x86_64`.

Growing major version

Posted Feb 17, 2026 14:22 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Fun, so 4.5 and 5.5 overlap then? Yeah, I think anyone who needed this has since migrated. Of course, those without the ability to recompile may be stuck with oodles of other bugs. And it's not as if they'd be able to care about 4.4 vs. 5.4 without fixing the behavior anyways.