# Greptimedb Release

Runbook for publishing a new GreptimeDB version (tag + GitHub release + docs...

- Repository: https://github.com/GreptimeTeam/greptimedb (6778 stars)
- Category: Git and review
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add GreptimeTeam/greptimedb --skill greptimedb-release -g -a claude-code -y`
Codex: `npx skills add GreptimeTeam/greptimedb --skill greptimedb-release -g -a codex -y`
Cursor: `npx skills add GreptimeTeam/greptimedb --skill greptimedb-release -g -a cursor -y`
Gemini CLI: `npx skills add GreptimeTeam/greptimedb --skill greptimedb-release -g -a gemini-cli -y`

## Description

Runbook for publishing a new GreptimeDB version (tag + GitHub release + docs release-note PR) on the upstream GreptimeTeam/greptimedb repo. Use when asked to "release" / "publish" a GreptimeDB version (e.g. v1.1.0, v1.0.3).

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

The rest: https://github.com/GreptimeTeam/greptimedb/blob/HEAD/.agents/skills/greptimedb-release/SKILL.md