Commonalities release versioning

[eric-murray]

Problem description
The current proposal for the "name" (i.e. version) of the next Commonalities release is "0.5.0". The issues with using semantic versioning for Commonalities documentation are:

• Using semantic versioning with major version 0 rather begs the question as to when the Commonalities documentation will become "stable". There are no agreed criteria that would result in a major version bump.
• The release is a set of documents and artifacts that may have their own separate release number. Using semantic versioning for both the release as a whole and documents within may cause confusion if and when these version numbers diverge.

Expected action
Herbert has made a proposal in Release Management to adopt the same release notation as is used for sub-projects, decoupling the release version number from the separate version number (if any) of the included documents and artifacts. If this proposal was adopted, then the next release (likely an "alpha") would be named r2.1, with subsequent versions resulting in a minor version bump until the final version for the next meta-release is declared.

This proposal should be discussed within Commonalities

Additional context
API (sub-project) release numbering rules are documented here

[rartych]

The version of Commonalities can be indicated in the VERSION file in the main folder of the repository.
Specific artifacts can be additionally versioned according to needs in the content of the respective files.

@tanjadegroot Am I right that the release version number is decoupled from meta-release process?
If so, then the next Commonalities release should start from r1.1.

[eric-murray]

@rartych
For sub-projects, the major version number refers to the meta-release. So 1 is Fall24, 2 is Spring25 and so on.

To my mind, Commonalities (and ICM) should adopt the same approach. So Commonalities (pre-)releases for the Spring25 meta-release should be numbered r2.x. That way, it will be known that the "final" Commonalities release for a given meta-release will be the highest minor version for the associated meta-release major version number, even though the final minor version cannot be set in advance and can always be updated (e.g. patch releases to fix documentation errors).

[eric-murray]

@rartych
Turns out I was wrong about the relationship between the major version number and the meta-release. So the major version is bumped only after an API has been included in a meta-release, but is not bumped if an API is not included in a meta-release. So any new API for the next meta-release would be r1.y, whereas APIs that were in the Fall24 meta-release would be r2.y.

Commonalities was part of the last meta-release, but did not use the rx.y notation. So indeed I think we do need to start at r1.1.