| name | create-release |
| description | Create a new release for ide. Use when the user says "create a release", "new release", "cut a release", or "ship it". |
Create Release
Cut a new GitHub release for ide using the versioning and release workflow this
repo expects. Publishing the release triggers the full Build and Test workflow,
which builds, signs, notarizes, and ships the app, so treat this as an
outward-facing action and get it right the first time.
Preconditions
Confirm all of these before creating anything:
- The release targets
main.
- The working tree is clean.
- Every release secret lives in the GitHub
prod environment, not as a
repo-level secret:
APPLE_ID
APPLE_TEAM_ID
APPLE_APP_PASSWORD
DEVELOPER_ID_CERTIFICATE
DEVELOPER_ID_PASSWORD
HOMEBREW_TAP_DEPLOY_KEY
Publish a real release, not a draft, when the user expects the pipeline to run
immediately — a draft does not trigger the workflow.
Steps
-
Pull latest:
but clean --pull
-
Confirm the checkout is clean:
but status -fv
Stop if there are uncommitted or unapplied changes that are not part of the
release, and tell Gordon what is dirty.
-
List existing releases:
gh release list --repo GordonBeeming/ide --limit 10
-
Determine the next version:
- Tags are
v{major}.{minor}. The release workflow rejects any tag without
the leading v.
- During the CI build the workflow writes
{major}.{minor}.{github_run_number}
into package.json, src-tauri/tauri.conf.json, and src-tauri/Cargo.toml,
so the packaged app and About dialog carry a valid three-part version based
on the run number.
- With no releases yet, use
v0.1 unless Gordon asks for another version.
- For a normal feature release, bump the minor version.
- Keep patch numbers out of release tags.
-
Gather the changes since the last release:
LAST_TAG=$(gh release list --repo GordonBeeming/ide --limit 1 --json tagName --jq '.[0].tagName')
git log "${LAST_TAG}..HEAD" --oneline
With no prior release, use:
git log --oneline
-
Create the release on main. Use a published release (not a draft) when the
user wants the pipeline to start now.
gh release create v{major}.{minor} \
--repo GordonBeeming/ide \
--target main \
--title "v{major}.{minor} - {short description}" \
--notes "$(cat <<'EOF'
# ide v{major}.{minor} - {short description}
## What's new
- {list changes since the last release using git log}
## Install
```bash
brew upgrade --cask gordonbeeming/tap/ide
```
Or download the DMG from the assets below after the release workflow completes.
EOF
)"
-
The release pipeline then runs on its own:
- Runs the verification suite
- Builds the Tauri app bundle
- Signs with Developer ID
- Notarizes with Apple
- Staples the notarization ticket
- Creates
ide-{version}-aarch64.dmg
- Uploads the DMG to the release
- Updates
GordonBeeming/homebrew-tap at Casks/ide.rb
-
Watch the workflow:
gh run list --repo GordonBeeming/ide --workflow "Build and Test" --limit 5
For the relevant run:
gh run watch <run-id> --repo GordonBeeming/ide --exit-status
-
Report the release URL, workflow run URL, Homebrew cask update status, and any
manual follow-up.
Version Format
- Release tag:
v{major}.{minor} (example: v0.2)
- App/package version during CI:
{major}.{minor}.{github_run_number}
- Homebrew cask version:
{major}.{minor}
- DMG asset:
ide-{major}.{minor}-aarch64.dmg
- Homebrew URL generated by CI:
https://github.com/gordonbeeming/ide/releases/download/v#{version.major_minor}/ide-#{version.major_minor}-aarch64.dmg
Guardrails
- Never reuse, delete, or overwrite an existing release tag.
- Always keep the
v prefix; never use a patch number in a release tag.
- Keep release credentials in the GitHub
prod environment only — do not create
repo-level secrets.
- If signing fails because
DEVELOPER_ID_CERTIFICATE or DEVELOPER_ID_PASSWORD
is missing, report that exact missing secret rather than working around
signing.
- Wait for the release workflow to finish before telling the user to run
brew upgrade.