Bumps the version, commits, tags, and pushes to trigger a GitHub release. Use when the user says "push and release", "release", "bump and release", or similar.
Bump the project version, commit all changes, tag, and push to trigger the GitHub Actions release workflow (.github/workflows/release.yml).
Read Cargo.toml and parse the current version field.
Decide which semver component to bump:
| User says | Bump | Example |
|---|---|---|
| (nothing specific) | minor | 0.2.0 → 0.3.0 |
| "patch" / "bugfix" | patch | 0.2.0 → 0.2.1 |
| "major" | major | 0.2.0 → 1.0.0 |
| an explicit version (e.g. "make it 1.0.0") | use that version exactly | — |
When bumping, always reset the components to the right of the bumped component to zero (e.g. minor bump: 0.2.3 → 0.3.0).
Cargo.tomlEdit the version = "..." line in Cargo.toml to the new version.
Run:
cargo build
This accomplishes three things:
Cargo.lock with the new version automatically.env!("CARGO_PKG_VERSION").Then verify the binary reports the correct version:
./target/debug/dbloada --version
Expected output: dbloada <new_version>. If it does not match, stop and investigate.
Run git status and git diff to review what will be committed. Ensure there are no unintended changes. If there are untracked files that look unrelated, ask the user before staging them.
Stage and commit. Always include Cargo.toml and Cargo.lock. Also include any other modified tracked files that are part of this release.
git add Cargo.toml Cargo.lock <other changed files>
Write a commit message following the Conventional Commits format. Choose the prefix based on what changed:
| Prefix | When to use |
|---|---|
feat: | New features or capabilities were added |
fix: | Bug fixes |
chore: | Version bump only, no functional changes |
refactor: | Code restructuring without behavior change |
If the commit includes a mix of changes, use the prefix that best describes the most significant change. Always mention the new version number in the message body or subject.
Example: