From 10b6ac31bf697844f04c56b39932615090777a4d Mon Sep 17 00:00:00 2001 From: Dylan Verheul Date: Sun, 11 Oct 2026 11:11:41 +0200 Subject: [PATCH] Write down two things releasing the fleet taught today Both raised by the django-bootstrap4 session after cutting 26.3 with these tools, so both are observed rather than imagined. release-check prints "(none)" for the Unreleased entries in the window between merging the release PR and pushing the tag, next to every commit since the previous tag. Stamping the section removes the heading the recipe looks for, and the tag it compares against is still the old one. Correct, and it reads as if the changelog has been lost. MAINTAINING.md now says what it means. This never showed up here because marina's tag sits on HEAD, so both lists are empty and the pair looks consistent. The fresh-Unreleased rule from #693 only helps if whoever propagates remembers it, and the failure is quiet. bootstrap4 rebased its release branch onto a propagation PR and git filed that PR's two changelog entries at the foot of the dated section with no conflict. They belonged in that release, so the result was right by luck rather than by anyone deciding. PACKAGING.md now says so, because a rule whose violation produces a correct answer is one people stop applying. MAINTAINING.md is synced, so its half goes to the four siblings. PACKAGING.md exists only here. Co-Authored-By: Claude Opus 5 (1M context) --- CHANGELOG.md | 5 +++++ MAINTAINING.md | 5 +++++ PACKAGING.md | 6 ++++++ 3 files changed, 16 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index f6aab8a..c7397f1 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,11 @@ ## Unreleased +- Say in MAINTAINING.md that `just release-check` reporting no `Unreleased` entries straight after a cut means nothing is pending, not that the changelog was lost. +- Say in PACKAGING.md that git files a propagation's changelog entry under a freshly dated heading silently, so the fresh-`Unreleased` rule only helps if it is remembered. + +## Unreleased + - Fix the numbering of the release-note ordering list in MAINTAINING.md, broken while renumbering the release process in the previous change. - Show commits that touch nothing in `src/` in `just release-check` as a second group, instead of hiding them. Tooling, CI and documentation changes belong in the release notes too, and the old output read as a complete list while being a filtered one. - Fail `just build` when `uv.lock` does not name the version in `pyproject.toml`, and add `just relock` to fix it. `uv sync --frozen` does not check the project's own version, so a stale lock passed every packaging check. diff --git a/MAINTAINING.md b/MAINTAINING.md index 30f4d8e..74e544e 100644 --- a/MAINTAINING.md +++ b/MAINTAINING.md @@ -97,6 +97,11 @@ it half-updated. Dependabot reopens it on the next run. gate or a contributor policy belongs in the notes under tooling. django-marina 26.3 shipped with nine such changes unrecorded, and django-bootstrap4 and django-bootstrap5 each found four or five more of their own, because the recipe only showed the first group. + Straight after a cut, in the window between merging the release PR and pushing the tag, this + prints `(none)` for the `Unreleased` entries next to every commit since the previous tag. + That is correct and it means nothing is pending: stamping the section removed the heading the + recipe looks for, and the tag it compares against is still the old one. It does not mean the + changelog was lost. 2. On a release branch, update `CHANGELOG.md`, bump `version` in `pyproject.toml`, and run `just relock` so `uv.lock` names the new version; open a PR and merge it. `uv sync --frozen` does not check the project's own version, so a stale lock otherwise survives every packaging diff --git a/PACKAGING.md b/PACKAGING.md index b8d17c8..9b76d7b 100644 --- a/PACKAGING.md +++ b/PACKAGING.md @@ -162,3 +162,9 @@ If a release PR is open in a sibling, land it or close it before propagating the propagation lands first and `## Unreleased` has meanwhile become a dated heading, add a fresh `## Unreleased` for the entry. Don't let git merge it into the released section, which it will do without a conflict, because the two sides touch different lines. + +That rule only helps if whoever propagates remembers to apply it, and the failure it prevents +is quiet enough to miss. django-bootstrap4 watched it happen while cutting 26.3: rebasing the +release branch onto a propagation PR filed that PR's two changelog entries at the foot of the +dated section, no conflict raised. They belonged in that release, so the result was correct by +luck. Git chose it, not a person, and nobody would have caught it had it been wrong.