@@ -17,7 +17,7 @@ So, currently each "step" is done as a separate job, which can be inefficient.
# Component Versioning
We rely on GitLab CI/CD [Components](https://docs.gitlab.com/ci/components/) to make reusable workflows. It's common practice for users to refer to a component by major version, which results in using the latest version in a major version series and thus automatically receiving bug fixes and backwards compatible enhancements.
It appears GitLab does this differently than GitHub. We're coming from GitHub and migrating/translating workflows. With GitHub reusable workflow authors must manually [move a major version tag themselves](https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions#using-tags-for-release-management). It appears GitLab allows users to refer to a major version and will [automatically figure out the latest tag](https://docs.gitlab.com/ci/components/#semantic-version-ranges) of that major version. However, another difference is by convention GitHub often uses a `v` prefix on tag names, whereas GitLab conventionally may not. More investigation needed as it appears the automatic determination if latest tag at a given major version assumes no `v` prefix (in the examples anyways). So at the moment, I'm still manually moving a major tag as before with:
GitLab does this differently than GitHub. We're coming from GitHub and migrating/translating workflows. With GitHub reusable workflow authors must manually [move a major version tag themselves](https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions#using-tags-for-release-management). It appears GitLab allows users to refer to a major version and will [automatically figure out the latest tag](https://docs.gitlab.com/ci/components/#semantic-version-ranges) of that major version. However, another difference is by convention GitHub often uses a `v` prefix on tag names, whereas GitLab conventionally may not. For automatic determination of latest tag at a given major version assumes no `v` prefix. We have adopted this approach to be compliant starting with version 2.x. With version 1.x we maintained the latest major tag manually (and with a `v` prefix) with:
