<!-- ## Implementation Issue To-Do list (_NOTE: This section can be removed when the issue is ready for creation_) - [ ] Ensure that issue title is concise yet descriptive - [ ] Add `Frontend :` or `Backend: ` per group [naming conventions](https://about.gitlab.com/handbook/engineering/development/ops/verify/pipeline-authoring/#splitting-issues) - [ ] Ensure the issue containing the feature or change proposal and related discussions is linked as related to this implementation issue. - [ ] Aside from default labeling, please make sure to include relevant labels for `type::`, `workflow::`, and `~frontend`/`~backend` labeling. - [ ] Issues with user-facing changes should include the `~UX` label. --> ## Summary Support shorthand referencing for semantic versioning, like so: ```yaml include: - component: gitlab.com/group1/project1/component1@1 ``` ## Proposal For `1` -\> it will return the latest version of the minor OR patch for version `1` For `1.1` -\> it will return the latest patch (or minor if no patch) ## Confirm purpose and User Reception (how does this benefit the user?) ## Additional details <!-- _NOTE: If the issue has addressed all of these questions, this separate section can be removed._ --> Some relevant technical details, if applicable, such as: - Does this need a ~"feature flag"? - Does there need to be an associated ~"instrumentation" issue created related to this work? - Is there an example response showing the data structure that should be returned (new endpoints only)? - What permissions should be used? - Is this EE or CE? - [ ] EE - [ ] CE - Additional comments: <!-- ## Documentation _NOTE: This section is optional, but can be used for easy access to any relevant documentation URLs._ --> ## Links/References