From e0f62d7a1fee277e4a3cb408c45cb7579fd5e6c4 Mon Sep 17 00:00:00 2001 From: Ripley Date: Tue, 18 Aug 2026 02:55:12 -0500 Subject: [PATCH] docs: log the numbered-version policy and what it changed Co-Authored-By: Claude Opus 5 (1M context) --- docs/history/DEVELOPMENT_LOG.md | 49 +++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/docs/history/DEVELOPMENT_LOG.md b/docs/history/DEVELOPMENT_LOG.md index 5fa6049..7ad7228 100644 --- a/docs/history/DEVELOPMENT_LOG.md +++ b/docs/history/DEVELOPMENT_LOG.md @@ -46,6 +46,55 @@ sequence would have implied more. ## Entries +### 2026-08-18 — Policy: production always runs a numbered version + +`_null`: *always stay on a num version.* Recorded here because it changed three +things, and one of them was a script written an hour earlier. + +**What a pointer cannot do**, which is the whole argument. A stack file naming +`:dev` says `dev` today and will still say `dev` after the image underneath it +changes. The file records a preference, not a fact, so "what is running?" has no +answer that survives the next push — and rollback is worse, because there is +nothing to roll back *to*. A pointer only ever names now. + +**`deploy.sh`** now resolves the newest published **numbered** version from the +registry when no `--tag` is given, and says which it picked. A floating tag is +refused outright. `--allow-floating` is the escape hatch for the one case that +is not a mistake — reproducing a fault on whatever a pointer currently is — and +it warns every time. + +**`release.sh` stopped moving `:dev`.** It published both tags when it was +written, because stack 58 followed the pointer. Under this policy nothing +deploys `:dev`, so publishing it would only put something misleading in front of +whoever reads the registry next. + +**`scripts/docker-push.sh` was deleted**, with its npm script. Its entire job +was building and pushing an unnumbered `:dev` with no bump and no guards — the +exact thing the policy exists to prevent. It had been kept a few hours earlier +on the grounds that it was "what the muscle memory reaches for", which is a +reason to remove it rather than a reason to keep it: a command that quietly +violates a policy is how the policy stops being true. + +`:dev` and `:latest` stay in the registry, frozen rather than deleted. The +running container was created from `:dev`, and removing the tag an existing +deployment names is how a recreate fails to pull. + +**The policy is not yet true of production.** Stack 58 still pins `:dev`. The +first deploy made under it repoints the stack at a version, and only then does +the stack file answer the question on its own. That is also why the deploy +default resolves a version rather than reusing whatever the stack already names +— reusing it would have quietly perpetuated the thing being fixed. + +- **Closed:** none. Policy and tooling. +- **Next action:** `npm run release` (0.9.3 → 0.9.4, publishing a numbered image + that contains Batch 10's accessibility fixes), then + `npm run deploy -- --tag v0.9.4`. That pair moves stack 58 off `:dev` and onto + a number, ships the a11y work, and closes #212 — the CORS trailing slash is + corrected in the same stack file the deploy rewrites. Both need sign-off: the + deploy recreates the container and takes both front doors down together. +- **Blockers:** the deploy needs permission. Six issues remain blocked on the + site owner (#68, #110, #162, #213 in Batch 13; #69, #70 in Batch 14). + ### 2026-08-18 — A release command, and the deploy half PrivacyLLC's deliberately omits Asked to model the release script on PrivacyLLC-Web's. Read theirs (30 KB, and