Automate the version bump and tag
A manual bump-and-tag ritual replaced with a scripted one, dry-run first.
The ticket
Automate the version bump and tag step of the release.
Acceptance criteria
- The bump is derived from the merged changes rather than chosen by hand
- A dry run reports what it would do without doing it
- Dry-run output is attached
- The tag format matches the existing convention exactly
What lands as proof
Dry-run output on a real release branch, showing the version and tag it would create.
Why teams defer it
- Whoever does the release knows the steps, so the cost is invisible until they are away.
- Getting the version wrong is publicly visible and awkward to undo, which makes automating it feel risky.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: automate the version bump and tag step of the release. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means dry run on a release branch attached to the pull request, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.