Knowledge Hub

Releasing

Versioning is fully automated by semantic-release — there is no manual version input anywhere. The version is computed from the Conventional Commits on main since the last release tag:

This repo squash-merges PRs, so the analyzed commit subjects are PR titles. pr-title.yml lints every PR title into the conventional format — a free-form title would otherwise silently contribute nothing to any release.

Flow

1. Merge develop into main (or push to main).
2. release.yml runs:
   • plan — semantic-release --dry-run resolves the next version from the commits. No release-worthy commits → the run ends here as a no-op.
   • release (macOS runner) — lint + unit-test gates, signing setup, then semantic-release creates and pushes the bare x.y.z tag, and GoReleaser builds, signs and publishes the GitHub Release against it.
   • verify — the published Windows/macOS assets are downloaded on real runners and their signatures verified; a failure yanks the release + tag.
3. workflow_dispatch on main just re-evaluates the same rules (useful to retry after a rolled-back failure). Dispatching from any other branch fails the guard step by design.

Invariants (do not break)

• Tags are bare x.y.z (tagFormat in .releaserc.yml): the self-updater and wsllauncher download releases/download/<x.y.z>/… URLs with no v prefix.
• The workflow file must stay .github/workflows/release.yml and run from main: the self-updater pins the cosign signing identity to release.yml@refs/heads/main (internal/shared/selfupdate/cosign.go).
• GoReleaser owns the GitHub Release — notes are label-based via .github/release.yml (changelog.use: github-native); semantic-release deliberately has no github/notes plugin.

Release notes (categorized, label-based, per PR) and release versions (conventional-commit types) are thus decoupled: labels shape the changelog, types shape the version.

Binary signing is documented in release-signing.md.