v2 is the new tracking tag (#506)

We're about to cut a new major version of this action,
and we don't anticipate any further releases of the `v1`
line.

So I simply updated the automation to float the `v2` tag.

Technically we could make it so it intelligently looks at
the release number and updates the appropriate tag, but
that'd be a bit more work and we don't need that complexity
in this repo right now given our very infrequent cadence of
bumping major versions.

As explained in a [code comment](https://github.com/dependabot/fetch-metadata/blob/f2f0ad1522845af9cf040e91326888ed5d56e3f8/.github/workflows/release-move-tracking-tag.yml#L11-L28):
```
    # We have a choice - defensiveness vs convenience:
    # 1. Be defensive by filtering if the release doesn't look like a normal
    #    version, or if it's a patch release to an older version... the logic
    #    gets tricky quickly. Easiest way to be 100% sure is stop running this
    #    on `release` and instead require a human to manually run this workflow
    #    after they tag a release.
    # 2. Minimize the upfront hassle by assuming every release is a normal
    #    version release and the latest one. Today both are resoundingly true
    #    as this repo isn't that active/busy, so we don't worry about
    #    multiple release branches, pre-releases, etc.
    #
    # For now I've gone with option 2, as it is much more convenient and if we
    # typo something during a release it's easy to fix by immediately tagging a
    # correct release. And if we don't notice the typo, well, in that case
    # requiring a human to manually run the workflow wouldn't have protected us
    # either, we'd have had to filter by only things that look like versions.
    # Anyway, for now this is good enough, and if it gets to be a problem down
    # the road we increase the robustness of this.

```

.github/workflows/release-bump-version.yml

@@ -87,4 +87,4 @@ jobs:
           echo "    > https://github.com/${{ github.repository }}/releases/tag/untagged-XXXXXX" >> $GITHUB_STEP_SUMMARY
           echo "    # Use the generated URL to review/edit the release notes." >> $GITHUB_STEP_SUMMARY
           echo "\`\`\`" >> $GITHUB_STEP_SUMMARY
-          echo "Once the release is tagged, another GitHub Action workflow automatically moves the floating \`v1\` tag to point at this release." >> $GITHUB_STEP_SUMMARY
+          echo "Once the release is tagged, another GitHub Action workflow automatically moves the floating \`v2\` tag to point at this release." >> $GITHUB_STEP_SUMMARY

.github/workflows/release-move-tracking-tag.yml

@@ -40,11 +40,11 @@ jobs:
           token: ${{ steps.generate_token.outputs.token }}
 
       - name: Move the tracking tag
-        run: git tag -f v1
+        run: git tag -f v2
 
       - name: Push the new tag value back to the repo
-        run: git push -f origin refs/tags/v1
+        run: git push -f origin refs/tags/v2
 
       - name: Set summary
         run: |
-          echo ":rocket: Successfully moved the \`v1\` tag to point at release: ${{ github.event.release.name }} with SHA: \`$GITHUB_SHA\`." >> $GITHUB_STEP_SUMMARY
+          echo ":rocket: Successfully moved the \`v2\` tag to point at release: ${{ github.event.release.name }} with SHA: \`$GITHUB_SHA\`." >> $GITHUB_STEP_SUMMARY

README.md

@@ -204,7 +204,7 @@ jobs:
   1. Run the action to generate a version bump PR.
   2. Merge the PR.
   3. Tag that merge commit as a new release using the format `v1.2.3`. The job summary contains a URL pre-populated with the correct version for the title and tag.
-  4. Once the release is tagged, another GitHub Action workflow automatically moves the `v1` tracking tag to point to the new version.
+  4. Once the release is tagged, another GitHub Action workflow automatically moves the `v2` tracking tag to point to the new version.
 
 </p>
 </details>