From 0278c5fd06475ac9fbea5a36ead2dd0ceecb2053 Mon Sep 17 00:00:00 2001 From: serversdown Date: Fri, 18 Sep 2026 18:04:54 +0000 Subject: [PATCH] docs: make the release cadence explicit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Brian described the practice: Unreleased is the staging area for what is going into the next release, and the version bump happens when enough has accumulated to be worth shipping — not per commit, not per merge. The convention already implied it ("never touch the changelog at a merge boundary") but never said it outright. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Qcu9ByJfuKBQxmrWb8rSrN --- CLAUDE.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index 1b4855e..2fb3b50 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -63,6 +63,10 @@ at a merge boundary.** polling cadence, or the monitor fan-out. The meter has a **single TCP slot**, so a change that bounces the connection is an operational event, not just a code change. +- **Releases are cut on judgement, not on a schedule or a merge.** `Unreleased` + is the staging area for whatever is going into the next release; when enough + has accumulated to be worth shipping, it gets a number and a date. Nothing + about a merge to `dev` triggers a release. - **Cutting a release** is its own `chore(release): vX.Y.Z` commit on `dev`, renaming `## [Unreleased]` → `## [X.Y.Z] - YYYY-MM-DD` and bumping the version in `app/main.py` (the FastAPI `version=` argument).