Growing major version

Posted Feb 13, 2026 16:04 UTC (Fri) by corbet (editor, #1)
In reply to: Growing major version by alx.manpages
Parent article: The first half of the 7.0 merge window

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