Prepare a release
Version Cue and publish a GitHub release.
Pushes do not create releases
Normal commits, pull requests, and pushes do not change Cue's version or publish a release. A release is an explicit maintainer action.
Prepare the version and notes
From the repository root, choose the next semantic version and synchronize both package manifests and the Homebrew formula:
pnpm version:cue 0.2.0
pnpm changelog:newReplace 0.2.0 with the version being released. The first release can use the version already in the package manifest. The version command updates the formula URL and marks its SHA-256 as pending. The changelog command creates changelogs/v0.2.0.mdx; edit the file to describe the changes users will notice. Use normal Markdown and keep the version and date in its frontmatter.
Build and validate the release
For public distribution, use the same Apple Developer ID Application identity across versions. Obtain a Developer ID Application certificate and install it in your login keychain, then set its identity name while packaging. Apple also recommends notarizing apps distributed outside the Mac App Store.
If you do not have a Developer ID certificate yet, you can explicitly build an ad hoc signed release:
pnpm changelog:check
CUE_ALLOW_ADHOC_RELEASE=1 pnpm release:cue
pnpm version:checkThis archive has no verified Apple publisher identity and is not notarized; macOS may ask users to approve Cue before launch. To create a Developer ID-signed archive instead, set CUE_CODESIGN_IDENTITY:
CUE_CODESIGN_IDENTITY="Developer ID Application: Your Name (TEAMID)" pnpm release:cueOn an Apple Silicon Mac, either command builds release-assets/cue-X.Y.Z-macos-arm64.tar.gz, calculates its SHA-256, and writes the checksum into Formula/cue.rb. The formula, package versions, archive URL, and notes must agree before publishing.
Publish on GitHub
Install GitHub CLI and authenticate once with gh auth login. Commit and push the version, formula, and changelog changes. Then run:
pnpm release:publishThis checks that the worktree is clean and the release commit is synced with its upstream branch. It creates and pushes the v0.2.0 tag, then creates a GitHub Release in the Cue repository, attaches the archive, and uses the matching MDX changelog body as release notes. It can finish a release again if the tag was pushed but the GitHub Release step failed.
After publication, the matching formula URL resolves to the attached asset. Homebrew users can discover it with brew update and install or upgrade Cue from the tap.
The release packager currently supports Apple Silicon only. Do not publish a release until the changelog, archive, formula checksum, and version checks all pass.
When moving from an ad hoc build to a Developer ID-signed release, macOS may ask users to authorize Cue for Accessibility again once. Later releases signed with the same identity retain the app's code identity. See Apple's code-signing requirements and notarization guidance.