Two interacting bugs produced v1.3.1-rc.4 today:
1. release-cut.yml used `gh release list --exclude-pre-releases` to
find latest_stable. That filter checks the GitHub `isPrerelease`
flag, which had been flipped to `false` on several RC releases
(including v1.3.22-rc.2 and v1.3.1-rc.3). The query returned an
RC tag, and bump() then silently mis-parsed `1.3.1-rc.3` via
`Number("1-rc") = NaN` -> `(NaN||0)+1 = 1`, yielding base=1.3.1.
Fix: filter by tag shape (no `-rc.`) in jq so an RC tag can never
be treated as stable, regardless of metadata. Also strip any
prerelease suffix in bump() and semver_gt() so the numeric math
is robust even if a caller passes a dirty input.
2. release.yml's final publish step only ran `--draft=false`, leaving
the `prerelease` flag at whatever electron-builder last wrote. When
that flag ended up false on an RC, GitHub marked the RC as the
"latest" release.
Fix: re-assert `--prerelease=<derived from tag>` alongside
`--draft=false` so the final state is a function of the tag name,
not of any intermediate publisher behavior.
Co-authored-by: Orca <help@stably.ai>
The rc branch previously derived the base version from the highest
git tag, which reopened an already-shipped series: after v1.3.21
stable was published, cutting an RC still produced v1.3.21-rc.N.
Anchor RCs to latest_stable + patch so a fresh RC after v1.3.21
correctly resolves to v1.3.22-rc.0. Minor/major RCs are cut by
running that stable kind first, which is a clearer workflow than
the old heuristic.
Co-authored-by: Orca <help@stably.ai>
Replaces the `stable` + optional `version` inputs with explicit
`rc | patch | minor | major` choices. Stable kinds are always computed
off the latest published stable release (ignoring intermediate RCs), so
there's nothing to type and no way to pick a version that regresses
electron-updater.
The stable-must-strictly-increase guard stays in place for patch/minor/
major. RC behavior is unchanged — continues an active series or starts
a new one on the next patch.
Replaces the local `pnpm release:{rc,patch,minor,major}` scripts with a
single manually-dispatched GitHub Actions workflow (`release-cut.yml`)
that takes `kind` (rc|stable), an optional `ref`, and an optional explicit
`version`.
Why: cutting releases locally was too easy to get wrong — `npm version
prerelease` behaves differently depending on whether the current version
is already an rc, there was no guard against tagging a dirty tree or an
off-main branch, and the "bad commit just landed, release the previous
one" case had no first-class answer. The new workflow:
- Resolves the next version automatically from GitHub Releases (or takes
an explicit override).
- Refuses to cut a stable release whose version isn't strictly greater
than the latest published stable. This is the only invariant
electron-updater needs within the `latest` channel.
- Only fast-forwards `main` with the version-bump commit when the caller
released the tip of `main`. Off-main releases publish only the tag, so
main is never polluted by a one-off RC against a feature branch.
CONTRIBUTING.md now documents the new flow with the common scenarios
(normal release, bad-commit-revert-to-previous-SHA, one-off RC, explicit
minor/major). The scheduled RC cron in release-rc.yml is untouched.
NeilandOrca