Pipeline-Notes.md

@@ -19,7 +19,11 @@ Another experimental feature, [Steps](https://docs.gitlab.com/ci/steps/) may mak
 So, currently each "step" is done as a separate job, which can be inefficient.   We could potentially collapse many jobs that are really steps into a single job even without steps at the cost of a big complex script.
 
 # 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, automatically using the latest version in a major series and thus receiving bug fixes and backwards compatible changes.  
+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.
+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:
+```
+git tag -f v1
+git push --tags -
+```