name: version-release description: Use when bumping version, creating a release tag, or pushing a version tag. Triggers on "version up", "release", "tag push", "bump version".
Version Release
Workflow for updating the version in Cargo.toml, creating a git tag, and pushing it.
Workflow
- Check current version: Get current version with
grep '^version' Cargo.toml. - Propose the next version from commits since the last tag:
- Find the previous release tag:
git describe --tags --abbrev=0 --match 'v*' - List every commit since that tag:
git log <prev-tag>..HEAD --oneline - Classify the commits using the Pre-1.0 Bump Policy below, decide
patch/minor/major, and present the proposed version number to the user before editing any files. Do not skip this step even for a single commit — the user should always see the commit range and the classification you used.
- Find the previous release tag:
- Update version: Edit the
versionfield in Cargo.toml using the Edit tool. - Sync the Claude Code plugin manifest: Edit
.claude-plugin/plugin.jsonand update itsversionfield to the same value. The two MUST stay in lockstep —tests/plugin_hooks_tests.rsenforces this. Without bumping plugin.json, users who installed via/plugin installwill not see the new release because Claude Code uses this field for update detection. - Regenerate Cargo.lock: Run
cargo checkto update Cargo.lock - Run checks: Run
cargo fmt --check && cargo clippy && cargo test - Commit: Commit
Cargo.toml,Cargo.lock, and.claude-plugin/plugin.json(message example:Bump version to X.Y.Z) - Create and push tag:
git tag vX.Y.Z && git push && git push origin vX.Y.Z
Pre-1.0 Bump Policy
This project is still pre-1.0, so SemVer is relaxed: the major stays at 0
and breaking changes ride on minor bumps.
| Signal in commit range | Bump | Example |
|---|---|---|
Any feat: / new user-visible behavior / breaking change |
minor | 0.5.2 → 0.6.0 |
Only fix: / refactor: / chore: / docs: / test-only |
patch | 0.5.2 → 0.5.3 |
Post-1.0 only: breaking change (feat!:, BREAKING CHANGE footer) |
major | 1.x → 2.0.0 |
Rules of thumb when classifying:
- Treat any
feat:commit as a minor bump trigger, even if the rest are fixes. - Docs-only or CI-only commit ranges still ship as a patch (never skip the version bump — the tag is what downstream plugin managers key off).
- If the range is empty (no commits since the last tag), stop and tell the user there is nothing to release.
- When in doubt between patch and minor, show the commit list and ask the user.
Quick Reference
| Bump type | Example |
|---|---|
| patch | 0.2.0 → 0.2.1 |
| minor | 0.2.0 → 0.3.0 |
| major | 0.2.0 → 1.0.0 |
Notes
- Tags use the
vprefix (e.g.,v0.2.0) - Always pass CI checks (fmt, clippy, test) before creating a tag
- Commit
Cargo.locktogether withCargo.toml