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.
# 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.
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: