releaselisted

# Cutting an ochakai release A release is a tag. Everything else is automation — but three files carry a version number the tag does not update, the release body is only as good as the tag message it is copied from, and a pushed tag is permanent because the Go module proxy caches it forever. So the work is: a reviewed PR, then a tag, then verification. [CONTRIBUTING.md](../../../CONTRIBUTING.md) is the reference; this skill is the running order and the traps. ## 0. Find out where you actually are Never infer the current version from `CHANGELOG.md` alone — it is what a PR *proposes*, not what is published. ```bash gh release list --limit 5 && git fetch --tags && git log --oneline -5 origin/main ``` Then decide the number. While the major version is 0: - any **BREAKING** entry in the unreleased section → bump the **minor** - otherwise → bump the patch Check CI is green on `main` before starting. Do not prepare a release on top of a red main. ## 1. The preparation PR Branch off `origin/main`. Three files, all of which drift silently — nothing fails when they are stale: 1. **`CHANGELOG.md`** - `## [Unreleased]` → `## [x.y.z] - YYYY-MM-DD` (tag date, JST) - add a fresh empty `## [Unreleased]` above it - at the bottom: add `[x.y.z]: …/compare/v<prev>...vx.y.z` and repoint `[Unreleased]` at the new tag 2. **`api/openapi.yaml`** — `info.version` 3. **`.github/ISSUE_TEMPLATE/bug_report.yml`** — the version placeholder Read the unreleased entries as you go and