The Cut Release workflow (cut-release.yml) performs the whole procedure below without a workstation. Run it from Actions -> Cut Release -> Run workflow, entering the new version (e.g. 0.3.2, no v prefix).
It replicates the workstation steps: builds and runs the tests on a Windows runner, stamps the version into main.go, README.md, and CHANGELOG.md, commits Release X.Y.Z, tags X.Y.Z, and pushes to master — which triggers the normal Release workflow chain.
Prerequisites:
CHANGELOG.mdmust have a populated## [Unreleased]section onmaster; the workflow renames it to## [X.Y.Z] - dateand uses it as the release notes. Keep release notes accumulating there as changes land.- The
WINGET_TOKENsecret must be set. The workflow pushes the tag with this PAT because tags pushed with the defaultGITHUB_TOKENdo not trigger other workflows (theReleaseworkflow would never run). - The workflow always releases from
master, regardless of which ref it is dispatched on.
Before releasing a new version:
-
Test the build locally
go build -o claude-code-switcher.exe -ldflags="-H windowsgui" .
-
Run tests
go test ./... -
Test the executable manually - verify the fix/feature works
Add a new section at the top (below the header):
## [X.Y.Z] - YYYY-MM-DD
### Added
- New features
### Fixed
- Bug fixes
### Changed
- Changes to existing functionalityUpdate the version number in the badge line:
> **Latest Version**: X.Y.Z | [See What's New](CHANGELOG.md)Update the appVersion constant:
const appVersion = "X.Y.Z"# Stage and commit your changes (if not already committed)
git add .
git commit -m "Description of changes"
# Commit the version bump
git add CHANGELOG.md README.md main.go
git commit -m "Release X.Y.Z"
# Create the tag (NO 'v' prefix - required for GitHub Actions)
git tag -a X.Y.Z -m "Release X.Y.Z"
# Push commits and tag
git push
git push origin X.Y.ZThe GitHub Actions release workflow triggers on tags matching [0-9]+.[0-9]+.[0-9]+.
- Correct:
0.1.1,1.0.0,2.3.4 - Wrong:
v0.1.1,0.1,release-0.1.1
When you push a correctly formatted tag, GitHub Actions will:
- Release workflow (
release.yml): builds the exe, extracts changelog, creates a GitHub Release with the binary attached - Publish to WinGet (
winget.yml): runs fromrelease.ymlviaworkflow_calland submits an updated manifest PR tomicrosoft/winget-pkgs(requiresWINGET_TOKEN) - Publish to Scoop (
scoop.yml): runs fromrelease.ymlviaworkflow_calland updatesfanis/scoop-appsbucket/claude-code-switcher.json - Publish to Chocolatey (
chocolatey.yml): manualworkflow_dispatchonly, used when you explicitly want to publish an already-released version to chocolatey.org (requiresCHOCO_API_KEY)
The package publishing workflows support workflow_dispatch, so a specific released version can be republished manually if needed without creating a new tag. Chocolatey is intentionally manual-only.
After pushing the tag:
- Check the
Releaseworkflow run: https://github.com/fanis/claude-code-switcher/actions - Verify the GitHub Release: https://github.com/fanis/claude-code-switcher/releases
- Check that
Publish to WinGetandPublish to Scoopran after theReleasejob. - If you want Chocolatey for that version, run
Publish to Chocolateymanually with the version input. - Check winget PRs: https://github.com/microsoft/winget-pkgs/pulls?q=ClaudeCodeSwitcher
- Check the Scoop bucket manifest: https://github.com/fanis/scoop-apps/blob/master/bucket/claude-code-switcher.json
- Check Chocolatey: https://community.chocolatey.org/packages/claude-code-switcher.portable
| Secret | Source | Purpose |
|---|---|---|
WINGET_TOKEN |
GitHub PAT with public_repo scope |
winget-releaser action pushes manifest PRs to microsoft/winget-pkgs; also used by Cut Release to push the release commit and tag so the tag triggers the Release workflow |
CHOCO_API_KEY |
Chocolatey account API key | choco push to chocolatey.org |