Release Guide¶
This guide describes the release workflow for CodeXomics. Historical release notes remain in this directory by version.
Version Sources¶
Keep these files synchronized for release work:
package.jsonpackage-lock.jsonafter runningnpm installor version toolingsrc/version.jsCHANGELOG.mddocs/release-notes/RELEASE_NOTES_v<major>.<minor>.mdmkdocs.ymlversion metadata when publishing documentation for a new release lineREADME.md,Agents.md, andMemory.mddocs/index.md,docs/zh/index.md, and both HTML pages indocs/landing/docs/user-guides/GETTING_STARTED.md
Use the existing version scripts where possible:
Pre-Release Checklist¶
- Confirm the working tree contains only intended changes.
- Run the relevant automated checks.
- Validate version consistency.
- Build the target platform packages.
- Smoke-test the packaged app.
- Update release notes.
- Commit with a conventional commit message.
- Tag the release.
- Publish GitHub release assets.
- Rebuild and publish GitHub Pages if public docs changed.
Checks¶
npm test
npm run lint
npm run version-validate
npm run tool-registry:validate
npm run test:coverage
npm run docs:validate
Run focused tests when the release touches a specific subsystem, for example MCP, plugin, benchmark, tool registry, or renderer modules.
Build Commands¶
The macOS build path uses the DMG background generation scripts before packaging.
Release Notes¶
Create release notes under docs/release-notes/ with a filename that includes the version, for example:
Recommended sections:
- Summary
- Highlights
- New features
- Fixes
- Developer notes
- Known issues
- Download links
Git Tag¶
Tag the merged release commit with the full semantic version prefixed by v.
GitHub Release¶
Dispatch Build Signed Update Release for the matching version tag. The workflow verifies native signing, update manifests and artifact checksums, and assembles a draft only after all platforms pass. Smoke-test real upgrades before publishing the draft; mark prerelease builds as prereleases. See the canonical release workflow for signing secrets, package compatibility and required assets.
GitHub Pages¶
The Pages source is docs/ and mkdocs.yml. Do not edit generated site/ output directly.
Before publishing, validate the canonical documents and strict site build:
GitHub Pages uses the Documentation workflow on main. Merge the documentation pull request or run the workflow manually on main to deploy that branch's docs. npm run docs:deploy builds and pushes the generated gh-pages branch.
Do not edit site/ or generated gh-pages content manually.