Pipeline-Notes.md

@@ -13,7 +13,7 @@ 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 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.  
+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.  
 
 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.