en un clic
release-engineering
// Manage the full software release process, including version bumps, changelogs, Git tags, and GitHub releases.
// Manage the full software release process, including version bumps, changelogs, Git tags, and GitHub releases.
Perform a project-wide code review covering security, correctness, code quality, documentation, UI/UX, and style.
Audit and update all project documentation to stay in sync with the current development status.
Audit and update project documentation to stay in sync with the current codebase and development status.
Perform a project-wide code review covering security, correctness, code quality, documentation, UI/UX, and style.
Stage, commit, and push changes to the remote repository with a well-formed commit message and body.
Manage the release process, including build verification, version bumps, changelogs, tags, and GitHub releases.
| 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.