ICM Release Versioning

[eric-murray]

Problem description
The current proposal for the "name" (i.e. version) of the next Identity & Consent Management documentation release is "0.3.0". The issues with using full semantic versioning for this documentation are:

• Using semantic versioning with major version 0 rather begs the question as to when the 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 r1.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 ICM and the conclusions fed back to Release Management

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

[jpengar]

@hdamker 's proposal seems good to me. It would be a matter of seeing what version we put on existing documents (I suppose initially v0.2.1 for all of them) and how we mark that version (in the filename? in the document content? both?...).

[eric-murray]

Apparently the first release using the rx.y notation should always be r1.1, irrespective of what has come before. I updated the issue description.