GreptimeDB Release Runbook

Publish a formal GreptimeDB release on GreptimeTeam/greptimedb. Always operate against that repo (for gh, pass --repo GreptimeTeam/greptimedb). Changelog generation is a separate, involved task, use the greptimedb-release-note skill for it.

This whole flow touches public infrastructure. Confirm with the user before the outward-facing step (creating the release, which creates the tag and triggers CI).

Prerequisites & remote

• Tools: gh (check with gh auth status) and git. Changelog generation additionally needs git cliff and Python, see the greptimedb-release-note skill.
• Resolve the remote first. This runbook writes <remote> for the git remote pointing at GreptimeTeam/greptimedb; substitute your actual name (often upstream, sometimes origin on a direct clone):

  git remote -v | grep -i 'GreptimeTeam/greptimedb' | awk '{print $1}' | head -1
  

0. Inputs: version and branch

• Ask the user for the version to release (e.g. 1.1.0, 1.0.3) and, if needed, the branch.
• Branch is inferred from version: MAJOR.MINOR → release/v<MAJOR>.<MINOR>.
  • v1.0.0 / v1.0.1 / v1.0.2 live on release/v1.0; v1.1.0 lives on release/v1.1.
  • Infer it, then double-check with the user.
• New minor/major (X.Y.0) is cut from main. If release/vX.Y does not exist on the remote, offer to create it from the intended main commit (with the user's consent): git push <remote> <commit>:refs/heads/release/vX.Y.
• Patch (X.Y.Z, Z>0) must use the existing release/vX.Y branch (it carries cherry-picked commits).
• Check what exists on the remote: git ls-remote --heads <remote> 'release/*'.

1. Verify the Cargo version