From ed6dfb95587383a52b1081e322fa928ba2fbbcb5 Mon Sep 17 00:00:00 2001 From: JohnnyT Date: Mon, 14 Sep 2026 04:43:46 -0600 Subject: [PATCH] Drops the literal version from the pin example The pin-form section illustrated the patch-component rule with today's literal values, which the same file forbids twice: it "carries no version string anywhere", and "the pin's current value is not written down here". The example now reads in the X.Y.1 / ~> X.Y.0 form, so it stays correct as releases accumulate and cannot go stale the way a named SHA would. The reference rule at the top said the latest prep commit beats this file where they disagree, while the pin-form section says release commits older than the 2026-09-13 form change are not evidence for that question. The rule now carries a one-clause carve-out pointing at the section. Docs-only: no Elixir code, no also-gated path, no version bump, no changelog fragment. --- .claude/wurk/release.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/.claude/wurk/release.md b/.claude/wurk/release.md index 3fc521c..87dbc49 100644 --- a/.claude/wurk/release.md +++ b/.claude/wurk/release.md @@ -18,7 +18,8 @@ git log --oneline --no-patch -L '/@version/,+1:mix.exs' The first line is the last commit that moved `@version`, and the last commit that moved `@version` is the last release prep by definition. Where this file and that commit disagree, the commit is the evidence and this file is the -defect. +defect - except the pin form, which this file answers rather than a previous +release commit (see "The README install pin" below). **This file names no SHA for that reference, on purpose, and it carries no version string anywhere.** A hard-coded reference stops being the most recent @@ -147,8 +148,8 @@ demonstrate another. Two consequences a prep should not have to derive: - The patch component is always the literal `0`, never the release's own - patch number. A `0.10.1` prep leaves both pins reading `~> 0.10.0`, which - already admits `0.10.1`; only a major or minor release moves them. + patch number. An `X.Y.1` prep leaves both pins reading `~> X.Y.0`, which + already admits `X.Y.1`; only a major or minor release moves them. - The skill's own wording for this step - the constraint bumps to the new major/minor, dropping the patch component, "in whatever form previous releases used" - is answered here rather than by reading a previous release