You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The v8 release https://github.com/actions/github-script/releases/tag/v8 should point to v8.0.0 instead of v8.
The v8 tag is a variable tag that will be moved eventually once v8.0.1 comes out. Creating a release with that tag is incorrect and will lead to weird behavior.
Are you sure that's the case? Aren't tags just associated to a git commit? GH releases should be pinned by the commit not the tag?
The tag references a commit. As you can see the latest 7.x release shares the same commit as the v7 tag. GH Releases link may be presenting the v8 tag simply because it shares the same commit as the v8.0.0 tag and via a sort order it is the tag that is presented in the rendered output. Probably not the case as v7.1.0 doesn't show v7 (but that may also depend upon when the tag was updated?).
If the release process hasn't actually changed, you'd find that once the v8 tag is reassigned, the v8.0.0 release page you've captured would present the v8.0.0 tag with the commit unchanged. You can already see the "Full Changelog" text is a range between the explicit full semver tags.
Should be easy enough to verify what happens via a private repo?
If what you're saying is the case, then the v8.0.0 release page would be erased once the v8 release updates to a new commit no?
My expectation is the v8.0.0 tag will point to the GH release page and present as you'd expect, and the v8 tag would then point to the commit of the next release tag. This is perhaps an error from which tagged commit is initially associated to the release, but not necessarily problematic?
Activity
polarathene commentedon Dec 11, 2025
Are you sure that's the case? Aren't tags just associated to a git commit? GH releases should be pinned by the commit not the tag?
The tag references a commit. As you can see the latest
7.xrelease shares the same commit as thev7tag. GH Releases link may be presenting thev8tag simply because it shares the same commit as thev8.0.0tag and via a sort order it is the tag that is presented in the rendered output. Probably not the case asv7.1.0doesn't showv7(but that may also depend upon when the tag was updated?).If the release process hasn't actually changed, you'd find that once the
v8tag is reassigned, thev8.0.0release page you've captured would present thev8.0.0tag with the commit unchanged. You can already see the "Full Changelog" text is a range between the explicit full semver tags.Should be easy enough to verify what happens via a private repo?
v8.0.0release page would be erased once thev8release updates to a new commit no?v8.0.0tag will point to the GH release page and present as you'd expect, and thev8tag would then point to the commit of the next release tag. This is perhaps an error from which tagged commit is initially associated to the release, but not necessarily problematic?