Re-lock after the release PR bumps the version

[mikeallisonJS]

pyproject.toml is the single version source, but uv.lock keeps its own copy of it in the cadent entry — and nothing re-locked after the bump. The two had drifted two releases apart:

pyproject.toml   version = "0.4.0"
uv.lock          name = "cadent"
                 version = "0.2.0"

So every uv sync regenerated that entry and left a dirty uv.lock in the working tree. That's easy to mistake for unrelated churn and revert — which is exactly what I did twice while working on #7 before stopping to look at why it kept coming back.

It is harmless only by luck. No workflow passes --locked or --frozen today; the first one that does would fail on a clean checkout.

The fix

scripts/release.py prepare now runs uv lock immediately after writing the version, so this holds whether the release PR drives it or a human does. A missing uv is a hard failure rather than a skip — a release that quietly leaves the lock behind is precisely how this accumulated.

uv.lock is regenerated in this commit to close the existing gap.

Why this doesn't drag in dependency updates

uv lock re-resolves but keeps every version it can, so a version bump rewrites one field. Verified rather than assumed — regenerating the committed lock reported:

Resolved 70 packages in 986ms
Updated cadent v0.2.0 -> v0.4.0

and the diff contains exactly one changed version line, one moved cadent block, no other package touched, and the same total line count:

version lines changed:   +version = "0.4.0"  /  -version = "0.2.0"
package blocks touched:  +name = "cadent"    /  -name = "cadent"
line count:              1491 -> 1491

relock() is also idempotent — running it against the regenerated lock leaves the bytes unchanged.

Testing

uv run ruff check scripts/release.py clean; scripts/release.py next-version still reports correctly (0.5.0, from the pending fragment on main).

Fragment is chore — release tooling, nothing user-facing, so it never renders into the changelog.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@mikeallisonJS, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 23 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ef797cfb-8bb3-4967-9ca5-1be6cc1c39c7

📥 Commits

Reviewing files that changed from the base of the PR and between a0b43c4 and 3927346.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• changelog.d/9.chore.md
• scripts/release.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}