cosmo-release

Cosmo Release

Use this workflow for release requests such as /cosmo:release v0.1.0-rc1.

Workflow

1. Normalize the target version.

   • Accept v0.1.0-rc1 or 0.1.0-rc1.
   • Use the normalized version without v for source files.
   • Use the tag form with v for changelog and release commands.

2. Inspect release readiness first.

   node scripts/release-preflight.mjs <version> --json
   

   Report pending version-string updates, current branch, changelog status, and the generated follow-up commands before making edits.

1. Local preparation is allowed.

   • Update version strings with:

     node scripts/release-preflight.mjs <version> --write
     

   • Generate or refresh the root changelog with:

     node scripts/generate-changelog.mjs <version> --write
     

   • Re-run preflight after edits.

2. Build and validate locally when feasible.

   • Fast checks:

     node scripts/release-preflight.mjs <version> --json
     node --test cmd/cosmo/*.test.mjs
     parse-changelog ./CHANGELOG.md
     

   • Full release build:

     COSMO_OUTPUT=target/dist/cosmoc ./scripts/build.sh
     target/dist/cosmoc --version
     

3. Generate release notes from the changelog and artifact directory.

   node scripts/draft-release.mjs <version> --artifacts target/release --output target/release-notes.md
   

4. Stop before external side effects.

   • Do not run git tag, git push, gh release create, gh release edit, or any publishing command unless the maintainer explicitly approves that exact action.
   • When asking for approval, show the exact command that would run.

Guardrails

• Do not update samples, fixtures, or docs examples that intentionally use 0.0.0.
• Keep cosmoc --version aligned with the release version.
• CI release builds produce cosmoc-linux-x64, cosmoc-linux-arm64, cosmoc-macosx-x64, cosmoc-macosx-arm64, cosmoc-windows-x64, and cosmoc-windows-arm64.
• Keep root CHANGELOG.md in tinymist-style sections: ## vX.Y.Z - [YYYY-MM-DD], ### Topic, * item, and a **Full Changelog** line.
• Use gh api repos/<owner>/<repo>/releases/generate-notes for changelog candidates.
• Use parse-changelog ./CHANGELOG.md for release notes so CI and local output agree.