buildpacks
provide a "moving" v5 tag
It would be convenient for users of your GitHub Actions to have a "moving" vMajor tag. That allows them--for example--to always use the latest v5.x.x by specifying uses: buildpacks/github-actions/setup-pack@v5.
Note that this aligns with the guidance here: https://docs.github.com/en/actions/creating-actions/releasing-and-maintaining-actions#example-developer-process
We recommend creating releases using semantically versioned tags – for example, v1.1.3 – and keeping major (v1) and minor (v1.1) tags current to the latest appropriate commit.
Currently, only full x.y.z tags exist, so users have to pin to the specific version and periodically bump their tags:
@edmorley ... I see you were recently added as a codeowner to this repo, and your commit history here suggests that you do some care and feeding of GitHub Actions automation.
Do you know whether or not this issue is something that is trivially addressable, either by changes to https://github.com/buildpacks/github-actions/blob/main/.github/workflows/pb-update-draft-release.yml , or using that action's release-drafter/release-drafter along with https://github.com/salsify/action-detect-and-tag-new-version per its docs?
A "moving" vMajor tag on this repo would make it much easier for users to stay up to date.
+1 - we should do this. This is the noisiest GHA in all of my code repos because there's no moving tag.
For the setup-pack action, I don't think this needs a change to the way that the repo is tagging the specific version. You still need to tag a specific release version. The moving tag needs to be changed after the fact to point to the same place as the new version-specific tag. At least that's how I've done this elsewhere.
One way I think we could do this is to add a new action that runs on release or on a new specific tag (although that would be tricky so you don't cause a loop), then have that update the major tag to point to the new release.
A number of the other actions are built as containers and get run that way. Those would require a different process. We'd need to modify the action-* actions to also tag those container images with the major version tag. This is a little more complicated because these actions are not maintained manually, but by the pipeline-builder tool which generates and synchronizes them. I think this open issue would encompass this change already.
