Document the two-line release process for stable v2
Claude / Claude Code Review
completed
Jul 28, 2026 in 16m 57s
Code review found 1 important issue
Found 5 candidates, confirmed 9. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 1 |
| 🟡 Nit | 7 |
| 🟣 Pre-existing | 1 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟡 Nit | RELEASE.md:82-86 |
Maintenance post-release check fails whenever the newest v2 tag is a pre-release |
| 🟣 Pre-existing | RELEASE.md:7-8 |
Stale dependency-bump step: uv lock --resolution lowest-direct would mass-downgrade the committed lockfile |
Annotations
Check warning on line 86 in RELEASE.md
claude / Claude Code Review
Maintenance post-release check fails whenever the newest v2 tag is a pre-release
The maintenance section's post-release check — "confirm `/releases/latest` still names the newest v2 tag" — is literally unsatisfiable whenever the newest v2 tag is a pre-release (e.g. `v2.1.0b1`), which is the normal cadence this doc documents: pre-releases are never Latest, so `/releases/latest` correctly names an older stable while the check reads as failed. One-word fix: "newest v2 tag" → "newest stable v2 release", matching the pre-release section's own wording.
Check notice on line 8 in RELEASE.md
claude / Claude Code Review
Stale dependency-bump step: uv lock --resolution lowest-direct would mass-downgrade the committed lockfile
Pre-existing issue (this line is unchanged by the PR): step 2 of "Bumping Dependencies" says "Upgrade lock with `uv lock --resolution lowest-direct`", but that command doesn't upgrade anything — it re-resolves every direct dependency down to its declared floor, mass-downgrading the committed `uv.lock` (pydantic 2.12.5 → 2.12.0, typer 0.17.4 → 0.16.0, …) and persisting `resolution-mode = "lowest-direct"` so later plain `uv lock` runs silently stay in that mode. Since this PR's purpose is making R
Loading