Proposal for Versioning system

Beman Project Development
1

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?

2

Thanks – this looks like an interesting approach. Of course it requires some coordination with repo owners – but we’ll need to do that anyway.

Can you explain ‘done automatically’ – is this just some cmake foo I don’t know about?

3

I’m a bit confused. Are these three different beman versions? Or, are these different versions of the Random library?

4

Can you explain ‘done automatically’ – is this just some cmake foo I don’t know about?

I fully admit I’m hand-waving here. I’m imaging some custom CMake functions that would take the CPP version that’s been supplied to CMake and then construct the appropriate version key for Beman.

I would suggest that we provide through some mechanism Beman FetchContent functions for CMake. What you could do is:

FetchContent_Beman()

What that function would do is get the CPPVERSION, and then do a look up of the latest C++ language version. So if you had set:

  set_target_properties(target PROPERTIES CXX_STANDARD 26)

Then the function would get the latest Beman-26.*.

And perhaps we could have a function:

FetchContent_Beman(VERSION 26.3)

Which would get the latest Beman-26.3.*

Yes, I admit, hand-wavy…

5

These would be 3 concurrent versions of the Beman library.

Beman-23.200.0
Beman-26.100.0
Beman-29.50.0

The Random library itself would have its own versioning system.

Another way to view Beman would be as a “manifest” or collection of existing libraries. So in the example above, we could consider Random-1.2 being part of Beman-23.200.0, and Beman-26.100.0, Beman.50.0.

6

Thanks, that clarification helped.

From a user standpoint, is it possible for the Beman manifest to include everything (from a source-code standpoint) and when I try building it with my compiler/platform it’ll disable the ones that won’t compile because my compiler is outdated or broken? I worry about the complexity of having several “active” branches of Beman as opposed to a linear history.

7

From the discussion 5/20 we noted that some of these ideas could be accomplished by packaging instead of versioning.

Versioning with a straightforward convention may be better to do, and then fix things with tooling.

8

Coupling different libraries through some “Beman Version” is a bad idea. Each library should maintain its own versioning sequence independently of any others. Libraries don’t evolve at the same speed so mapping libraries to a “Beman version” will just create a bunch of unnecessary confusion. If dependencies are related to library versions the library version should be used.

9

This makes a lot of sense. And, welcome Robert! It’s great to see you here.

10

Hi Robert – good to see you!

Completely agree that libraries are changing at different rates – of course this is true in Boost as well and yet we have a top level version to refer to that is handy. I think the idea here is similar – that is a top level .json file versioned in Beman controls the specific version of the included sub-libraries. If you’re interested in only the sub-library, you don’t care about the Beman version at all. But if you’re interested in the entire collection then you grab something with a Beman version – which transitively selects a version of the sub-libraries.