Release workflow: always publish as a pre-release, to be promoted to latest by hand

Author: drowaudio

.github/workflows/build.yaml

@@ -238,8 +238,10 @@ jobs:
         uses: softprops/action-gh-release@v2
         with:
           body_path: CHANGELIST.md
-          # Tags like v2.0.0-beta1 are pre-releases, so they don't become "latest"
-          prerelease: ${{ contains(github.ref_name, '-') }}
+          # Every release is published as a pre-release, so it doesn't become the
+          # "latest" release (which the download URLs in the docs point at) until
+          # it's promoted by hand: gh release edit <tag> --prerelease=false --latest
+          prerelease: true
           files: |
             CHANGELIST.md/*
             pluginval_Linux.zip/*

CLAUDE.md

@@ -605,11 +605,12 @@ Run internal tests via CLI:
 3. Commit: `git commit -am "Version X.Y.Z"`
 4. Tag: `git tag -a vX.Y.Z -m "X.Y.Z release"`
 5. Push: `git push --tags`
-6. Once the release binaries are published, bump the `pluginval-version` default
-   in `validate/action.yml` and `acceptance/action.yml` (and the README tables) to the new tag
-
-A tag with a hyphen (e.g. `v2.0.0-beta1`) is published as a pre-release, so it
-doesn't become the "latest" release that the download URLs in the docs point at.
+6. The tag build publishes the release as a **pre-release** (whatever the tag), so
+   it doesn't yet become the "latest" release that the download URLs in the docs
+   point at. Check it, then promote it by hand:
+   `gh release edit vX.Y.Z -R Tracktion/pluginval --prerelease=false --latest`
+7. Bump the `pluginval-version` default in `validate/action.yml` and
+   `acceptance/action.yml` (and the README tables) to the new tag
 
 ## Common Tasks for AI Assistants