...
For Commonalities and ICM, their version is documented in a dedicated file “VERSION.yaml” in the home folder of the repository. The syntax contains “version: <version>” where version can have any number according to shall follow the same rules as the below referenced numbering API versioning scheme, e;g. for alpha, release-candidate and public versions.
...
release type | version | release number (tag) | release package label | Milestone |
|---|---|---|---|---|
N/A | wip | N/A | N/A | M/A |
pre-release | x.y.z-alpha.1..n | rm.1 ... rm.n | "pre-release" | M1 (internal pre-release) |
pre-release | x.y.z-rc.1..m | rm.n+1 ... rm.n+k | "pre-release" | M2 (internal pre-release) |
release | x.y.z | rm.p (p=n+k+1) | "latest" | M4-2 weeks (public) |
maintenance release | x.y.z+1..k | rm.p+1 ... rm.p+q | "latest" | After M5 (public) |
Additional versioning of artifacts
Some artifacts inside Commonalities or ICM that may have their own version. For changes of such artifacts, the following versioning guidelines are provided:
If a versioned artifact change impacts the APIs, then the artifact version and the repository version in the VERSION.yaml file should be changed accordingly (MAJOR, MINOR, PATCH), and a new release shall be created.
If a versioned artifact change impacts does not impact the APIs, then the artifact changes can be done outside a release with their version being updated inline with semver guidelines. The changes shall be included in the next repository release, but the advantage is that the latest updates are available in main, and can be referenced with their version.
An example of the latter could be the update of a template that has its own version that does not impact APIs.
Note: these guidelines are provided, but it is not clear if such separate versioning is actually needed.
API Sub Projects
Release tracking
...