Release 1.10.0

[MattFisher]

Why

Prepares the v1.10.0 release of the template, which ships #6 (automated releases, uv_build libraries).

What changes

• The [Unreleased] entries move unchanged under ## [1.10.0] - 2026-10-03, with a short summary paragraph like recent releases.
• A [1.10.0] compare link is added, and [unreleased] now compares from v1.10.0.
• [Unreleased] is left empty.

I ran bump-v1.yml's own changelog check against the edited file for v1.10.0: "changelog documents 1.10.0, and [Unreleased] is empty".

Releasing after merge

• Publish a release named exactly v1.10.0 from the merge commit, targeting main. The copier migration that keeps a library's version across the update is keyed to v1.10.0, so another number would skip it or run it at the wrong time.
• bump-v1.yml then annotates the tag and moves v1. Check that git cat-file -t v1.10.0 prints tag and that v1 is on the merge commit.
• Once v1 moves, @v1 consumers get the new reusable workflows straight away. Scaffolded files arrive through copier update.

🤖 Generated with Claude Code

[MattFisher]

Review of the 1.10.0 changelog

The release mechanics check out. One upgrade step is missing, plus two smaller wording points. Most important first.

1. Upgrading misses --trust for a manual copier update (CHANGELOG.md:31-36)

#6 added the template's first _migrations entry (copier.yml:15). Copier treats migrations as an unsafe feature, so any copier update that crosses v1.10.0 stops unless it passes --trust. This hits apps as well as libraries: copier refuses before it evaluates the when: project_kind == 'library' condition.

Failure scenario: someone in a project on 1.9.1 follows the README (README.md:64, uvx copier update). Copier prints Template uses potentially unsafe feature: migrations. and changes nothing. I reproduced this with copier 9.18.2, in a library and in an app scaffolded from v1.9.1, updating to this PR's head tagged locally as v1.10.0. The weekly template-update.yml already passes --trust, so scheduled updates are fine. With --trust, the library update runs the migration, prints restored version 0.4.2, and only __init__.py conflicts, as the entry says.

Fix: add an Upgrading bullet, for example: "A manual copier update across 1.10.0 needs --trust, because the template now runs a migration. Without it copier stops with Template uses potentially unsafe feature: migrations. The weekly template-update workflow already passes it." Consider also changing README.md:64 to uvx copier update --trust, here or in a follow-up.

2. The summary paragraph is broader than what ships (CHANGELOG.md:19)

• "the merge tags the release, creates the GitHub release, and publishes to PyPI". Only a library with publish_to_pypi publishes. Apps and non-PyPI libraries get the tag and the release only.
• "a check of their version after copier update". That applies to libraries only, and libraries also need the wheel-contents check.

Failure scenario: an app maintainer reads the summary and expects a PyPI step. Or a library maintainer reads it as "check the version" and skips the wheel check.

Fix, for example: "... and merge: the merge tags the release and creates the GitHub release, and a library on PyPI is then published. Libraries now build with uv_build, with the version set once in pyproject.toml. Every project needs one repository setting, and libraries need to check their version and wheel after copier update; see Upgrading."

3. PR description: nothing in 1.10.0 reaches @v1 consumers straight away (PR body only)

The body says "Once v1 moves, @v1 consumers get the new reusable workflows straight away." #6 changed no reusable workflow (python-ci.yml, node-ci.yml, template-update.yml). Its only .github/workflows/ change is template-ci.yml. Every change in 1.10.0 is a scaffolded file, so it reaches a project only through copier update. Moving v1 still matters, because the weekly update defaults to --vcs-ref v1. This is not a changelog problem, but worth correcting so nobody expects CI behaviour to change once v1 moves. Optionally say it in the summary too: "Everything here is scaffolded, so it reaches a project through copier update."

4. Nit: ### Upgrading is a new heading style (CHANGELOG.md:31)

Earlier sections use only Added, Changed and Fixed. 1.9.0 put its upgrade steps in a bold "Upgrading an existing project:" bullet under Added. The separate heading reads better, and nothing parses it (bump-v1 only splits on ## ). Fine to keep. Flagged only for consistency.

Version number: keep 1.10.0

• The semver contract for this repo is the @v1 reusable-workflow interface. Automate releases: Prepare release and release-on-merge workflows #6 doesn't touch it.
• Scaffold changes reach a project as a reviewable update PR, here with a migration and Upgrading notes. 1.8.0 (mypy to basedpyright) and 1.9.0 (scriv, github_owner) shipped scaffold changes of similar weight as minors.
• The migration keeps each library's own version, so no generated project's release number moves.
• 2.0.0 would stall delivery. bump-v1.yml only acts on v1.* tags, so v1 would stay on 1.9.1. template-update.yml defaults to --vcs-ref v1, so no project would get the update until it re-pins. It would also need a v2 tag and its own bump workflow.
• The migration key fits. Copier runs it when to >= 1.10.0 > from, compared as PEP 440, so 1.10.0 sorts above 1.9.1. A lower number such as 1.9.2 would skip it.

What I checked and found fine

• bump-v1's changelog check, copied from the workflow and run on this PR's CHANGELOG.md for v1.10.0: changelog documents 1.10.0, and [Unreleased] is empty. On main's CHANGELOG.md it fails with "no '## [1.10.0]' section", so this PR is what lets the release pass.
• The other bump-v1 steps. A release published from the merge commit on main gives compare status identical (or behind if more lands first), so "Refuse to move v1 off main" passes. Annotate and Move have no other preconditions, and they worked for v1.9.1: v1.9.1 is an annotated tag and v1 is on the same commit.
• Prefix matching: [1.10.0] can't be confused with [1.1.0]. The check also still passes for v1.9.1 and v1.1.0.
• Added, Changed and the other Upgrading bullets match Automate releases: Prepare release and release-on-merge workflows #6's final diff: the uv_build requirement, static version, metadata __version__ with "unknown", the [tool.scriv] version source, MIT license-files, publish.yml's dispatch trigger, ref guard, tag check and action pins, the approval step, and the re-run behaviour. Nothing describes the dispatched ci.yml from Automate releases: Prepare release and release-on-merge workflows #6's first push.
• Links: [1.10.0] and [unreleased] follow the 1.9.0 and 1.9.1 pattern. compare/v1.9.1...HEAD resolves now. compare/v1.9.1...v1.10.0 returns 404 until the tag exists, as expected. The lowercase [unreleased] label matches earlier releases, and Markdown labels are case-insensitive.
• Template CI on this PR is green.

Posted by Claude Code on Matt's behalf.

[MattFisher]

Superseded by #8, which turns the release workflows into shared reusable ones and releases the template through them. Its first run produces the 1.10.0 changelog section, so this hand-written one isn't needed. The review points here are folded into #8's changelog fragment:

• the --trust upgrade step;
• the narrower summary: only PyPI libraries publish, and libraries check their version and wheel;
• 1.10.0 kept as the version.

The summary paragraph will be written on the release PR. I'm leaving this open for Matt to close.

Posted by Claude Code on Matt's behalf.