Release Process

Release Process

Releases are tag-driven. Pushing a v* tag builds the portable distribution, zips it, and creates a GitHub Release with auto-generated notes. The workflow is .github/workflows/release.yml.

Cutting a release

git tag v1.2.3
git push origin v1.2.3

That's the trigger — on: push: tags: ['v*']. There's nothing to do in the GitHub UI.

What the workflow does

Running on windows-latest with permissions: contents: write (the only job that can write):

1. Checkout (actions/checkout).
2. Set up the toolchain with jdx/mise-action — the same pinned .NET 10 / just as local and CI.
3. Publish with just publish → self-contained x64 build in dist/KeepPressing, then the TrimPortableDistribution target prunes MUI/pdb/unused DLLs (see Portable Distribution).
4. Package (PowerShell): strip the leading v from the tag and Compress-Archive dist/KeepPressing → keep-pressing-<version>-win-x64.zip.
5. Create the Release with softprops/action-gh-release, attaching the zip, generate_release_notes: true, and fail_on_unmatched_files: true.

v1.2.3 tag ─▶ mise setup ─▶ just publish ─▶ trim ─▶ zip ─▶ GitHub Release (notes + asset)

Versioning notes

• The release asset name derives from the tag: v1.2.3 → keep-pressing-1.2.3-win-x64.zip.
• Release notes are generated automatically from merged PRs/commits since the previous tag — which is why the commit-message and PR conventions in Contributing matter.
• The published artifact is x64 only. To ship other architectures you'd build them with just publish arch=… and extend the workflow.

---

Related: Portable Distribution · CI/CD · Contributing