CLI: Releases ​

Cut, ship, announce and roll back releases.

bumpkit analyze ​

Write the changelog and suggest the next version together.

bumpkit analyze [flags]

bumpkit bump ​

Suggest the next version from the commits since the last tag.

bumpkit bump [flags]

bumpkit changelog ​

Write a changelog from the commits since the last tag.

bumpkit changelog [flags]

bumpkit release ​

Grouped releases, and how a deployed release is doing in production.

Grouped releases ​

Beta, early access. Flag: grouped_releases.

release prepare finds the last release tag (or the first commit when there is none), lists the merged pull requests and commits, runs one check over the whole range, and suggests the version and notes. Preparing again refreshes the open draft. Approving is a person's call, so an API key can't do it on its own: release approve and release deny print a link and a one-time code, and the vote counts once you confirm it signed in to Bumpkit. release show --audience prints the notes that audience gets, and release notes replaces or regenerates them before you publish. release publish creates the tag and GitHub Release and updates the public changelog with the customer notes, posts the engineering notes to Slack, and updates any connected Notion or Confluence page with the engineering notes; settings set --publish-audience changes that. Each target is tried on its own: run it again to retry only the ones that failed. It exits 1 while a target still fails. Once a release is published, release correct fixes its notes: it updates the stored notes, the public changelog entry and RSS feed, the GitHub Release and any Notion or Confluence page that got them, and reports each target on its own. Slack messages aren't edited. Run it again to retry a target that failed; it exits 1 while one still fails. See Grouped releases and Correct published notes.

Release health ​

Beta, early access. Flag: release_health.

See Release Health & Forensics.

release health compares the production error rate after VERSION went live with the window before it. It flags new and spiking errors, and names the commits most likely behind them. It exits 1 when the release regressed.

bumpkit release health v2.3.0 --environment staging --window 30 --json

bumpkit train ​

Beta, early access. Flag: release_trains.

Group pull requests into a named release, see readiness across them, and cut it. Pull requests join a train when they carry its label (train:<slug> unless train.label in bumpkit.yml or --label says otherwise), belong to its --milestone, or are added with bumpkit train add. See Release Trains.

Every subcommand takes --repository (owner/name, default: the origin remote).

train multi and train map are early access under the multi_repo_trains flag; see Release across repositories.

train approve and train cut need a person signed in to the dashboard, so with an API key they print a HUMAN_APPROVAL_REQUIRED refusal with the link to the batch page. On that page, an approval covers the batch as it is now: adding a pull request or pushing to one changes the members, and approvals of the old members stop counting. A cut versions every commit on the train's branch since the last release tag, writes one changelog entry named after the train, and creates the tag and GitHub Release through the Bumpkit GitHub App, or runs train.release_workflow from bumpkit.yml instead. Starting it again returns the same cut.

bumpkit train new "Agent swarms"
bumpkit train add "Agent swarms" 482
bumpkit train show "Agent swarms"

bumpkit deploy ​

Beta, early access. Flag: release_health or forensics.

Record that a version went live, with the commits it shipped. The optional record word is accepted: bumpkit deploy record is the same command. See Release Health & Forensics.

bumpkit deploy [record] [--environment production] [--sha SHA] [--version V]

bumpkit deploy --environment production --version v2.3.0

bumpkit hotfix ​

Cut and track hotfix releases. See Hotfixes & Break Glass.

hotfix version prints the next patch version after the latest release tag reachable from HEAD, or after --from. Versions that already exist locally or on origin are skipped.

bumpkit backport ​

Beta, early access. Flag: close_the_loop.

Open the cherry-pick pull request for a shipped hotfix that's missing from main or a release branch. Bumpkit fetches the repository through its GitHub App, cherry-picks the hotfix onto the tip of --onto, and opens the pull request on bumpkit/backport/<sha7>-to-<branch>. The commit keeps (cherry picked from commit <sha>), so the missing back-port check clears once it merges. If the cherry-pick conflicts, Bumpkit opens nothing: the error names the conflicting files and the hotfix's author, and the release stays gated. There is one pull request per hotfix and branch, and Bumpkit never merges it. Members and above can open one. See Hotfixes & Break Glass.

$ bumpkit backport open 5322103231 --onto main
Error: Bumpkit API error (HTTP 409): Cherry-picking 5322103 (fix: charge 8% sales tax) onto main conflicts in billing/tax.go, so Bumpkit opened nothing. Sam Rivera <sam@acme.test> shipped it and needs to back-port it by hand; the release stays gated until it lands.

Use --check CHECK_ID to associate a backport with a saved release check. Bumpkit uses that check’s repository and requires the commit to match its checked head or a recorded missing_backport finding. A conflicting --repository is refused. Without --check, --repository or the current origin selects the repository.

bumpkit rollback ​

Beta, early access. Flag: intelligent_rollback.

Plan the smallest revert that undoes a regression, and open it. See Rollback & Time Machine.

rollback plan ranks every commit between --base and --head by evidence that it caused the failure. It then reverts the smallest set of commits that explains the failure, plus later commits that depend on them, with git revert --no-commit in a temporary worktree. Nothing in your checkout changes. With --incident, the stack trace and the regressed release come from that incident.

rollback open takes a plan id, an incident id, a check id or a release version like v1.5.0. Saved check and incident targets use their recorded repository even when your current checkout belongs to another repository. --repository owner/name must match that recorded repository; conflicting overrides are refused. For a release version, --repository selects the repository explicitly, otherwise the origin remote is used. With a plan id, it re-runs the revert in a temporary worktree and, if it still applies cleanly, Bumpkit opens the pull request through the Bumpkit GitHub App. With an incident, a check or a release (Beta, flag close_the_loop), Bumpkit plans and reverts on its side: it fetches the repository through the GitHub App, ranks the regressed release's commits by the incident's evidence, reverts them on the tip of --branch, and opens the pull request on bumpkit/rollback/incident-<id> or bumpkit/rollback/<release>. With no evidence pointing at specific commits, it reverts the whole release (up to 20 commits). If the revert conflicts, nothing opens and the error names the files.

With --to v1.0.0 (Beta, flag close_the_loop), Bumpkit takes the branch back to that release: it reverts every non-merge commit in the releases it checked after v1.0.0, up to the newest checked release on --branch, as one pull request on bumpkit/rollback/to-v1.0.0. Commits after that release that no checked release shipped stay. It prints the releases and commits first and asks before it opens anything. At most 100 commits and 300 changed files; over that, or on a conflict, nothing opens and the error gives the git revert command.

There is one rollback pull request per incident, release or --to version: running it again returns the open one. The gate runs on it like any pull request, and Bumpkit never merges it. Only a workspace owner or admin can open a rollback, and it's in the audit log.

bumpkit rollback plan --base v1.4.0 --head v1.5.0 --error "$(cat trace.txt)"
bumpkit rollback open --to v1.0.0

bumpkit notes ​

Beta, early access. Flag: audience_notes.

Generate, review and export saved release notes, or manage audiences, customer segments and feature tags. See Release Notes & Digests.

bumpkit notes list --repository acme/shop
bumpkit notes generate CHECK_ID --audience customer
bumpkit notes view CHECK_ID --output release-notes.md

Choose a check ID from notes list, which lists recorded checks and excludes working-tree checks. notes generate uses POST /checks/{id}/notes to generate and save a draft, or reuse an existing one. Add --regenerate only when you intend to replace that saved audience and segment draft.

notes view reads an existing saved draft without generating or replacing it. The dashboard's Markdown download also reads the saved draft only. Neither action publishes notes or sends messages.

Generating notes requires a writer identity: sign in with bumpkit login, or use an API key created by an active workspace member with write access. Legacy keys without an owning member cannot generate notes. Active workspace viewers and read-only users can view saved notes.

Both generate and view print the Markdown body to stdout by default. --output FILE atomically writes the exact saved body with owner-only permissions, and only after a successful API response; an API failure leaves an existing file unchanged and does not create a missing file. Use --json for the full response instead. Combining --json with --output is rejected before an API request.

notes generate and notes view flags:

notes audience set flags:

notes segment set flags: --features (features the segment uses), --name (the segment's name), --plan (the plan these customers are on). notes feature set flags: --keywords (words in changelog lines that belong to the feature), --paths (path globs that belong to the feature).

bumpkit digest ​

Beta, early access. Flag: weekly_digest.

Weekly digests: what shipped, what's risky and which agent did what. See Release Notes & Digests.

digest set flags:

bumpkit docs ​

Beta, early access. Flag: release_docs.

Release docs: engineering notes, customer notes and a migration guide. See Release Notes & Digests.

docs view flags:

docs publish needs a key created by an owner, admin, policy admin, approver or member. Other roles and keys not tied to a person get 403 ROLE_REQUIRED.

docs publish flags:

Beta: docs notes, guide and Notion or Confluence ​

Beta, early access. Flags: audience_notes, consumer_migration_guide, notion_confluence.

docs notes generates or reuses a saved draft; it is not a cached-only read. Use bumpkit notes view CHECK_ID when you only want an existing draft.

docs notes flags:

docs connect flags: