Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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. ```
- Loading branch information