This document describes the expected release shape for CliGate.
A normal tagged release is expected to produce:
- a GitHub Release
- desktop artifacts for supported platforms
- a published npm package
During development, the local repository is the source of truth for current work.
For shipped artifacts:
- Git tags define intended release versions
- GitHub Releases define published desktop artifacts
- npm defines published package availability
These three surfaces should not drift for long.
Before creating a release tag:
- confirm
package.jsonversion is correct - confirm
README.mdandREADME_CN.mdstill match the product - confirm
docs/product-manual.en.mdanddocs/product-manual.zh-CN.mdstill match the product - confirm release-facing screenshots are still current or note that they are deferred
- update
CHANGELOG.md - run release readiness checks
The current release workflow lives in:
.github/workflows/build-desktop.yml
It is expected to:
- verify tag and
package.jsonversion alignment - run release readiness checks
- publish npm
- build desktop artifacts
- create a GitHub Release
Two publish paths are supported:
- trusted publishing from GitHub Actions
NPM_TOKEN-based publishing
Trusted publishing is the preferred path for GitHub-hosted runners.
If you still use NPM_TOKEN, make sure it is a current publish-capable token for npm. Token and npm account configuration problems are a common cause of release failures.
If users report version drift, check these first:
package.json- the latest Git tag
- the latest GitHub Release
- the npm package page
- whether the release workflow completed successfully
- tag version does not match
package.json NPM_TOKENis missing or no longer valid- npm token permissions are insufficient for publishing
- npm package ownership is missing for the publishing account
- release docs were not updated and
release-checkfails
If a release changes onboarding, supported tools, routing behavior, or navigation, release-facing docs must be updated in the same release cycle.