Give 1.9.0 its changelog section, and describe 1.9.1

[MattFisher]

Why

The v1.9.0 release ran bump-v1.yml, which failed its changelog check: CHANGELOG.md has no '## [1.9.0]' section. Everything since 1.8.1 was still under [Unreleased]. So v1 still points at 1.8.1 (ba338ef), and the v1.9.0 tag stayed lightweight.

The workflow reads CHANGELOG.md at the tagged commit, so fixing main alone can't rescue v1.9.0. 1.8.1 set the precedent for this: cut a patch release rather than move a published tag.

What changes

• The [Unreleased] entries move unchanged under ## [1.9.0] - 2026-10-02.
• A ## [1.9.1] - 2026-10-02 section says 1.9.1 repairs 1.9.0 and has the same contents.
• [Unreleased] is empty, which the workflow also checks.

I ran the workflow's own parsing (split on ^## , look for [1.9.1], check that [Unreleased] is empty) against the edited file, and it passes.

After merge

Publish a v1.9.1 release from the merge commit. bump-v1.yml then annotates the tag and moves v1. The adopters (Generality-Labs/inspect-evals-lint#75, Generality-Labs/inspect_dataset#55) can record either tag, since the scaffolded contents are identical.

🤖 Generated with Claude Code

[MattFisher]

Review

The fix is sound. The workflow check passes for v1.9.1 on this branch, and a patch release is the right call. Two changelog gaps are worth fixing before merge, plus one nit.

Findings

1. CHANGELOG.md:219-220: no link definitions for the new versions, and [unreleased] still compares from v1.8.1.
Every earlier heading has a matching [x.y.z]: ...compare/... line at the bottom. This PR adds ## [1.9.0] and ## [1.9.1] without them.

• Scenario: on GitHub the two new headings render as plain [1.9.1] - 2026-10-02 text, while every other release heading is a link. The [Unreleased] link shows the 1.9.0 changes as still unreleased.
• bump-v1.yml only reads headings, so it won't catch this.
• Fix: replace line 220 with:

  [1.9.0]: https://github.com/Generality-Labs/python-project-template/compare/v1.8.1...v1.9.0
  [1.9.1]: https://github.com/Generality-Labs/python-project-template/compare/v1.9.0...v1.9.1
  [unreleased]: https://github.com/Generality-Labs/python-project-template/compare/v1.9.1...HEAD
  

2. CHANGELOG.md:21-54: the 1.9.0 section leaves out the action bumps in the reusable workflows.
git diff v1.8.1 v1.9.0 shows python-ci.yml and node-ci.yml moving astral-sh/setup-uv from v8.3.2 to v10.0.1 and actions/setup-node from v6.5.0 to v7.0.0 (#8, MattFisher#15), plus actions/checkout 7.0.0 to 7.0.1. Line 9 says changes to the reusable workflows reach every @v1 consumer as soon as v1 moves.

• Scenario: v1 moves, a consumer's CI breaks on a setup-uv or setup-node major-version change, and the changelog gives no hint why.
• Earlier sections don't list Dependabot bumps, so this is a judgement call. Two major bumps in shipped workflows still seem worth one line.
• Fix: add a bullet under ### Changed. For example: "python-ci.yml uses astral-sh/setup-uv v10 (was v8) and node-ci.yml uses actions/setup-node v7 (was v6). Both reach consumers when v1 moves."

3. Nit, CHANGELOG.md:31-43 and 47-50: two entries are hard-wrapped. Every other entry is one line per bullet. These came from [Unreleased] as they were, so unwrapping them is optional.

Release steps (no change needed)

• Publish a stable (not prerelease) release named v1.9.1, targeting main at the merge commit. Letting the UI create the tag is fine: it makes a lightweight tag and the workflow annotates it. Pushing an annotated tag first and then using --verify-tag also works, and the annotate step skips itself.
• If something else lands on main before you publish, targeting main still passes, as long as [Unreleased] is still empty.
• The annotate and move steps have never run in this fork. The only bump-v1.yml run here is the failed v1.9.0 run (36989184872), where those steps were skipped. They did succeed for 1.8.1 in MattFisher/python-project-template. The repo default token permission is read, and the job asks for contents: write explicitly. I couldn't read the org-level Actions policy (403). After publishing, check that v1 points at the merge commit and that git cat-file -t v1.9.1 prints tag.
• Don't re-run the failed v1.9.0 run. It reads CHANGELOG.md at d9bcc96, so it would fail the same way.

Patch release vs re-tagging v1.9.0

The patch release is right.

• Keep the changelog as scriv fragments inspect-evals-lint#75 and Keep the changelog as scriv fragments inspect_dataset#55 already record _commit: v1.9.0. Re-tagging would keep the name but move the commit under them.
• Moving a published tag means deleting and recreating the v1.9.0 release. Clones that already fetched v1.9.0 keep the old tag, because git fetch won't overwrite a tag without --force.
• copier.yml sets _subdirectory: template, and this PR only touches the root CHANGELOG.md. So v1.9.0 and v1.9.1 render the same files, and those two PRs can stay on v1.9.0.
• Scheduled template-update.yml runs use --vcs-ref v1. v1 is still on ba338ef (1.8.1), so those consumers haven't moved yet and will go straight to 1.9.1.
• Leaving v1.9.0 lightweight does no harm. v1 never sits on d9bcc96, so git describe --tags there still returns v1.9.0.

What I ran (fresh clone, local only, nothing pushed)

• Copied the check from bump-v1.yml and ran it:
  • This PR's CHANGELOG.md: passes for v1.9.1 and for v1.9.0 ("changelog documents ..., and [Unreleased] is empty").
  • CHANGELOG.md at d9bcc96: fails for both versions. The v1.9.0 error matches the failed run's log.
• Failed run step results: "Refuse to move v1 off main" passed, the changelog check failed, and annotate and move were skipped. Live refs: v1 is on ba338ef, v1.9.0 is lightweight on d9bcc96, and the only ruleset (protect-main) covers just the default branch, so it doesn't block tag writes.
• git diff --stat main pr-head: only CHANGELOG.md changes (6 lines added, none removed). Every [Unreleased] entry is kept word for word.
• Recreated the post-release tags locally on the PR head. With v1.9.1 annotated and v1 lightweight, git describe --tags returns v1.9.1. With both lightweight, it returns v1, the failure the annotate step prevents. At d9bcc96 it returns v1.9.0.
• The 1.9.1 note is accurate (v1 left on 1.8.1, 1.9.0 tag lightweight). Its wording matches the 1.8.1 repair note.

Posted by Claude Code on Matt's behalf.

[MattFisher]

Thanks. All three actioned in 22a76dd:

1. Links. Added [1.9.0] and [1.9.1] compare links, and [unreleased] now compares from v1.9.1.
2. Action bumps. Added a 1.9.0 ### Changed bullet. I checked the files first: setup-uv is only in python-ci.yml (v8.3.2 to v10.0.1), setup-node only in node-ci.yml (v6.5.0 to v7.0.0), and both take checkout 7.0.1.
3. Wrapping. Unwrapped the repo-settings and rebrand entries.

The workflow's changelog check still passes for v1.9.1 against the new file.

After publishing v1.9.1 from the merge commit, check that v1 points at the merge commit and that git cat-file -t v1.9.1 prints tag. The annotate and move steps have not run in this repo yet.

Posted by Claude Code on Matt's behalf.