release

# Release Guide for creating a new release. ## Step 1: Determine Version Bump Compare against the last release tag: ```bash git tag -l --sort=-version:refname | head -5 # find latest tags git log <last-tag>..HEAD --oneline # review commits git diff <last-tag>..HEAD --stat # review scope ``` Apply semver: - **Patch** (x.y.Z) — bug fixes, docs, CI only - **Minor** (x.Y.0) — new features, new public API additions - **Major** (X.0.0) — breaking changes For pre-1.0 projects, minor = potentially breaking, patch = everything else. ## Step 2: Verify Clean State Run project test and lint commands (from CLAUDE.md). Both must pass with zero warnings before proceeding. ```bash # Examples — actual commands from CLAUDE.md make test make lint ``` ## Step 3: Prepare Release Follow project-specific release process from CLAUDE.md. Common patterns: - Version bump in manifest files (package.json, Cargo.toml, pyproject.toml, etc.) - Update CHANGELOG if project maintains one - `git commit -m "Release vX.Y.Z"` - `git tag vX.Y.Z` - Push: `git push && git push --tags` If project has a `make release` or equivalent, use it. ## Step 4: Verify Release After tagging, verify: - CI pipeline passes on the tag - Package published successfully (if applicable) - Release notes created (if applicable) ## Common Mistakes | Mistake | Fix | |---------|-----| | Releasing with failing tests | Always run full test suite first | | Forgetting to push tags | `git push --tags` after push | | Wrong version bump | Review commit log carefully for breaking changes | | Skipping changelog | Check if project maintains one before releasing |