Pipeline-Notes.md

@@ -11,3 +11,9 @@ The `CI_PUSH_KEY_VALUE` CI Variable has the value set to `GROUP_PUSH_TOKEN:<Valu
 Another experimental feature, [Steps](https://docs.gitlab.com/ci/steps/) may make our pipelines easier to understand and more performant.  Steps don't appear to be supported on our code.jlab.org install at the moment.   A no step_runner found error results when attempting to use.
 
 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 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, thus automatically using the latest version in a major series and thus receiving bug fixes and backwards compatible changes.  
+
+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.
+