This is copied from a SEC conversation which discussed adopting full ADL2-lile template naming conventions.
One issue that arose was how much of the Semantic versioning (https://semver.org) rules should be adopted, in particular, the pre and post release numbering aspects.
For clarity, this is primarily about project-level artefacts, not really for CKM-type work, and mostly about templates, though I think it probably does apply to new archetypes.
I agree that it would be helpful to support more ânon-publishedâ parts of semver in tooling - @pablo - I think the earlier discussion on whether to support these or not was really centred on whether CDRs and REST API should support them, and there I agree they should not.
However, as @siljelb says. there is definitely value in having at least some support in tooling, especially for templates.
There is quite a lot of variation allowed in smver in this area - is it worth trying toprofile a subset of all of the options to make it easier for tooling implementers to support correctly?
- A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.â.
Personally, I would be happy with
1.0.0-alpha.1.x.y.z
(with alpha, beta, rc allowed ).
If an artefact is pre-release then tooling auto-updates the second set of semver numbers when it detects changes, rather than the first.
I think Iâd prefer to put some constraints on semver in its area, especially if that can help power some tooling support.
Our strong preference for new project level templates and archetypes is to start at 1.0.0-alpha, rather than v0, as this allows much easier transition into production, where we now have a policy of not deploying any .v0 archetypes.
From @siljelb
Iâd prefer being able to use
1.0.0-alpha+1.x.y.z
(including beta, rc) as well, to clarify that itâs a post-publication revision.I guess this could work for archetypes as well, but should we mandate the build versioning like
1.0.0-alpha.0.0.1
?