# Proposal for Versioning system

**URL:** <https://discourse.bemanproject.org/t/proposal-for-versioning-system/84>\
**Category:** Beman Project Development\
**Created:** [May 4, 2024, 7:45pm UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84 "2024-05-04T19:45:29Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![rmpowell77](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/rmpowell77/32/48_2.png) [@rmpowell77](https://discourse.bemanproject.org/u/rmpowell77)\
**Post date:** [May 4, 2024, 7:45pm UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/1 "2024-05-04T19:45:29Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Jeff-Garland](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/jeff-garland/32/23_2.png) [@Jeff-Garland](https://discourse.bemanproject.org/u/Jeff-Garland)\
**Post date:** [May 8, 2024, 3:32pm UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/2 "2024-05-08T15:32:13Z")

</div>

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

> [@rmpowell77](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [May 9, 2024, 7:30pm UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/3 "2024-05-09T19:30:07Z")

</div>

> [@rmpowell77](#):
>
> v23.200.0  
> v26.100.0  
> v29.50.0

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

---

<div class="post-metadata">

**Author:** ![rmpowell77](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/rmpowell77/32/48_2.png) [@rmpowell77](https://discourse.bemanproject.org/u/rmpowell77)\
**Post date:** [May 12, 2024, 5:38am UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/4 "2024-05-12T05:38:43Z")

</div>

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

```auto
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:

```auto
  set_target_properties(target PROPERTIES CXX_STANDARD 26)

```

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

And perhaps we could have a function:

```auto
FetchContent_Beman(VERSION 26.3)

```

Which would get the latest Beman-26.3.\*

Yes, I admit, hand-wavy…

---

<div class="post-metadata">

**Author:** ![rmpowell77](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/rmpowell77/32/48_2.png) [@rmpowell77](https://discourse.bemanproject.org/u/rmpowell77)\
**Post date:** [May 12, 2024, 5:41am UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/5 "2024-05-12T05:41:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [May 13, 2024, 5:43pm UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/6 "2024-05-13T17:43:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rmpowell77](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/rmpowell77/32/48_2.png) [@rmpowell77](https://discourse.bemanproject.org/u/rmpowell77)\
**Post date:** [May 27, 2024, 5:01pm UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/7 "2024-05-27T17:01:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ramey](https://avatars.discourse-cdn.com/v4/letter/r/5f8ce5/32.png) [@ramey](https://discourse.bemanproject.org/u/ramey)\
**Post date:** [June 11, 2024, 5:54pm UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/8 "2024-06-11T17:54:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [June 17, 2024, 3:20pm UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/9 "2024-06-17T15:20:47Z")

</div>

> [@ramey](#):
>
> Each library should maintain its own versioning sequence independently of any others.

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

---

<div class="post-metadata">

**Author:** ![Jeff-Garland](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/jeff-garland/32/23_2.png) [@Jeff-Garland](https://discourse.bemanproject.org/u/Jeff-Garland)\
**Post date:** [June 19, 2024, 2:44am UTC](https://discourse.bemanproject.org/t/proposal-for-versioning-system/84/10 "2024-06-19T02:44:54Z")

</div>

> [@ramey](#):
>
> 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”

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.