| name | release-engineering |
| description | Manage the full software release process, including version bumps, changelogs, Git tags, and GitHub releases. |
When performing release engineering, always follow these steps:
-
Verify the build is clean — before anything else, run ./scripts/clean-build.sh to confirm a from-scratch build passes. This mirrors CI (which never has a cached libmruby.a) and catches build-plumbing bugs that a normal cargo build would hide due to caching.
-
Determine the release type — review all unreleased commits since the last tag and classify the release as major, minor, or patch following Semantic Versioning. Present the recommendation to the user and confirm before proceeding.
-
Update the version — bump the version field in Cargo.toml to match the new release version.
-
Update CHANGELOG.md — add a new version entry at the top following the Keep a Changelog format. Group changes under Added, Changed, Fixed, Removed, or Security as appropriate. Include all notable changes since the previous release.
-
Commit the release — stage Cargo.toml, Cargo.lock, and CHANGELOG.md together and commit with the message chore: release vX.Y.Z.
-
Tag the release — create an annotated Git tag (e.g., git tag -a v1.2.3 -m "v1.2.3") and push both the commit and the tag to the remote (git push && git push --tags).
-
Create a GitHub release — use gh release create vX.Y.Z --title "vX.Y.Z" --notes "..." with the corresponding CHANGELOG.md section as the release notes. Note: use --notes (not --body) for the release description.
