Growing major version

Posted Feb 13, 2026 17:14 UTC (Fri) by daroc (editor, #160859)
In reply to: Growing major version by corbet
Parent article: The first half of the 7.0 merge window

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.

to post comments

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.