Backend: Enforce use of semantic versioning for catalog resources
Problem
The use of ~latest
version qualifier for CI components is not guaranteed to return the latest semantic version of the component. For example:
- Create and release a tag
v2.0.0
- Then, create and release a new tag
v1.5.0
- the
~latest
version returned will bev1.5.0
because under the hood we usereleased_at
field.
Challenges
The Release
model that powers the creation of new versions of catalog resources does not have knowledge of semantic versioning. It's possible to create releases as one
, two
, three
and the system not being able to understand that.
Proposal (Updated)
When a new version is created enforce the use of semantic versioning in thetag
. Fail with an error on version creation if thetag
does not follow the semantic versioningUpdate the default sort inVersionsFinder
to besemantic_version_asc
(name tbc)Update theorder_by
method inCi::Catalog::Resources::Version
to default tosemantic_version_asc
Ensure that~latest
version qualifier for CI/CD Components and skip versions marked asbeta/rc/alpha
.
Opportunities (out of scope for this issue and epic)
Semantic version enforcement could be a feature we could move downstream to Release
feature by allowing maintainers to enable a project settings. This means that maintainers can enforce the use of semantic versions for releases outside of catalog resources.
Edited by Laura Montemayor