I was chatting with Zach Laine about a versioning system for the Beman Project:
Major version indicates the C++ version that is targeted.
Minor version gets bumped when any of the Beman Project sub-Libraries has a new revision
Subminor version gets bumped if there is any project tooling changes necessary to support that version.
Using Major version to indicate the Language supported means that we could have automatic selection based on the version in the CMake of whoever’s building for automatic checkout. There’s also the interesting ability to have some libraries actively choose branches that drop support for a language that is too onerous.
Let’s say we have a library Random that has an r1 version that’s in Beman Project. And imagine that they have their own repository, versioning system, and it corresponds to say v1.2 in their own version/tag/git system. Let’s also say that the library owner has confirmed their library is supported in C++23, 26, 29. And let’s also further imaging Project Beman version that has that library is:
v23.200.0
v26.100.0
v29.50.0
(the idea is these versions have already existed for a while).
Now let’s say the developer updates their code to encompass feedback from the committee, users. They have updated their own versioning system to be v2.0. And with that version they drop support for C++23, but add for c++32. And so now they push to Beman. That would cause the following version increments:
v23.201.0 (has removed Random, or maybe keeps it in there with many deprecation notices…?)
v26.101.0
v29.51.0
v32.1.0
So this allows us have a way to have tooling for specific languages done in a way that doesn’t affect the projects themselves. Another detail is that it means that there would likely be many iterations of the minor version of the Beman Library. But that’s ok. Users of the library looking for a particular version would have to use “minimum” version or “maximum” version techniques. But this could be done automatically.
So let’s say that there was a tooling problem that needed to be address with C++32. Then our project maintainers would push that change and bump the sub minor version:
v32.1.1
And that change would likely forward to the the rest of the v32 project, or we could choose to make it specific for v32.1.
What do we think about this?