RFC: date-based version numbering? (2025 edition)

[ralfbrown]

Follow-on to #17505 to restart the discussion and hopefully have a final decision by summer.

Three main possibilities for a date-based approach to version numbers

• simply bump the major version every year (the GCC approach). Minimum change to existing practice, the December 2025 release becomes 6.0.0.
• two digit major version corresponding to the last two digits of the year
• four digit major version for the year

Previous discussion was largely against trying to use anything finer-grained than years, e.g. making the summer release N.6. Overall consensus seemed to be to retain the odd-dev, even-stable minor version numbers.

There was some talk of a possible disconnect from calling the December 2024 release version 2025.0, but it is in fact common to have a "Year N" version late in year N-1 (not just for automobiles, various other raw converters already had their first 2025 releases in Nov/Dec 2024).

Overall, this would give us version 6.0/26.0/2026.0 for the December 2025 release and 6.2/26.2/2026.2 for the summer 2026 release.

One other alternative to date-based versioning would be to simply declare each feature release a new major version (the clang/LLVM approach), patch releases N.1/N.2/etc, and call dev for the next feature release version N.9 which becomes (N+1).0 on release. So we could have 6.0 for summer 2025, 7.0 for December 2025, 8.0 for summer 2026, etc.

[victoryforce]

I'll add another possible scheme. In fact, we want to move away from numbering, which looks like semantic versioning, but in reality it's not. We can replace <major>.<minor>.<patch> of our current numbering scheme with <major>*10+<minor>.<patch>. That is, the summer release of 2025 will be 52.0, the winter release of 2025 will be 54.0. When the numbering reaches 58.0, the next version will naturally be 60.0, since now the versions are a single number, with even numbers corresponding to stable releases.

[MStraeten]

Why help some dubious review sites that their AI based review generation doesn‘t interpret a x.0 as a groundbreaking major release ;)

[parafin]

Or you can go with Linux kernel style version numbering, when you increase the major version whenever the minor grows too big to look nice. This essentially changes nothing from current scheme and hopefully avoids this bike-shedding discussion altogether. Really, people, version numbering doesn’t matter, like, at all, as long as it monotonically grows over time. This shouldn’t be a committee decision…

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[Donatzsky]

I like the Emacs version scheme. It neatly circumvents the whole even/odd and what about December discussion.

A version number with two components (e.g., ‘28.1’) indicates a released version; three components indicate a development version (e.g., ‘29.0.50’ is what will eventually become ‘29.1’).

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[wpferguson]

I guess I'm not sure what problem we are trying to solve. Everyone understands the numbering scheme as it is and no one seems to have a problem with it.

What do we gain by changing it?

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.