Skip to content

Release workflow: always publish as a pre-release, promote to latest by hand - #201

Merged
drowaudio merged 1 commit into
v2from
ci/releases-always-prerelease
Oct 15, 2026
Merged

drowaudio merged 1 commit into
v2from
ci/releases-always-prerelease

Conversation

@drowaudio

@drowaudio drowaudio commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor

Every tag build now publishes its release as a pre-release, whatever the tag. Previously only tags containing a hyphen (v2.0.0-beta1) were pre-releases, so tagging v2.0.0 would have made it "Latest" immediately, and every script downloading releases/latest would have moved from 1.0.4 to 2.0.0 at once.

Releases are now promoted by hand once checked:

gh release edit vX.Y.Z -R Tracktion/pluginval --prerelease=false --latest

What

  • build.yaml: prerelease: true on the release step.
  • CLAUDE.md: the release process says the release is published as a pre-release and how to promote it.

Effect on the GitHub Actions

None: they download pluginval by exact tag, which works for pre-releases (they already use the v2.0.0-beta3 pre-release). The plan is to switch their default pluginval-version to latest when 2.0.0 is promoted, so promoting a release is also what moves the actions on, and the per-release action.yml bump goes away.

Testing

Only runs on a tag push, so it'll be exercised by the next tag. The YAML parses, and the step's prerelease value is true.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need.

@drowaudio
drowaudio merged commit b7b33b6 into v2 Oct 15, 2026
12 checks passed
@drowaudio
drowaudio deleted the ci/releases-always-prerelease branch October 15, 2026 14:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant