From 251186e8a6a77ac48887407767bfc3b57fd6b3db Mon Sep 17 00:00:00 2001 From: garrytan Date: Wed, 28 Oct 2026 00:43:57 +0000 Subject: [PATCH] fix: the floor dates stable from its v tag, so a stray extra tag cannot stall cuts silently Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> --- CHANGELOG.md | 2 +- docs/releases.md | 12 +++++++----- scripts/release-cut.ts | 34 +++++++++++++++++++--------------- test/release-cut.test.ts | 21 ++++++++++++--------- 4 files changed, 39 insertions(+), 30 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 34fd8851c..ec841e356 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,7 +5,7 @@ **Stable moves twice a week, and never twice in 72 hours unless a security fix needs it.** Garry asked, 2026-10-27: "Do we have rules around stable where we update stable except for security fixes at most once every 72 hours?" There were none: the Monday cut and any hand-run cut moved team installs whenever someone ran it. Now the release cut runs Monday and Thursday at 14:00 UTC ("Ok twice a week"), refuses any move inside 72 hours of the last one, and lets a security fix through only when it can tie the fix to the commits being released. ### Added -- **The 72-hour floor in `scripts/release-cut.ts`.** Every cut, scheduled or by hand, measures stable's last move from the newest annotated `v*` tag on stable (or its GitHub Release's publish time when later) and refuses inside 72 hours. The refusal's first two lines are `REFUSED_FLOOR: stable moved to v at