## Problem The use of `~latest` version qualifier for CI components is not guaranteed to return the latest semantic version of the component. For example: 1. Create and release a tag `v2.0.0` 2. Then, create and release a new tag `v1.5.0` 3. the `~latest` version returned will be `v1.5.0` because under the hood we use `released_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 the `tag` . Fail with an error on version creation if the `tag` does not follow the semantic versioning~~ * ~~Update the default sort in `VersionsFinder` to be `semantic_version_asc` (name tbc)~~ * ~~Update the `order_by` method in `Ci::Catalog::Resources::Version` to default to `semantic_version_asc`~~ * ~~Ensure that `~latest` version qualifier for CI/CD Components and skip versions marked as `beta/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.