chore(version): restore the version past its high-water mark - #7222
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThe project version was restored from ChangesVersion restoration
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
3a979a0 to
24a82f0
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@changelog.d/7217-restore-version-high-water.md`:
- Line 1: Rename the changelog fragment from 7217-restore-version-high-water.md
to 7222-restore-version-high-water.md, preserving its existing contents and the
required <PR>-<slug>.md format.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: a45681b8-3524-4703-9254-2f28e991f146
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (3)
CLAUDE.mdCargo.tomlchangelog.d/7217-restore-version-high-water.md
main was at 0.5.1278 and regressed to 0.5.1277 when PerryTS#7196 merged from a stale base. Five commits have landed since without catching it, so main has been carrying a patch version it already shipped. Bumped to 0.5.1279 — the next unused patch above the old high-water mark — in Cargo.toml, Cargo.lock and the Current Version line.
24a82f0 to
00d4ab4
Compare
mainis publishing a patch version it already shipped. It reached 0.5.1278, then went backwards to 0.5.1277, and five commits have landed on top since without anyone catching it.This sets it to 0.5.1279 — the next unused patch above the old high-water mark — in
Cargo.toml,Cargo.lock, and the**Current Version:**line.How it happened — a stale base, merged without a rebase
#7196was branched whenmainwas at 0.5.1276 and bumped itself to 0.5.1277, which was correct at the time. While it sat in review,mainmoved to 0.5.1278. Merging it without a rebase carried the older version line in and overwrote the newer one.The version at each recent commit on
main:1679e22b4and earlier91170973c(#7196 merged)dd83c7e92a3496427b(#7206)fa4a7ab99(#7214)7d1dc9ca2(#7212)Nothing was wrong with any of those five PRs. The version is a single shared line that only the merge step touches, so once it went backwards it stayed there — each subsequent merge inherited the wrong value rather than re-introducing the problem.
Why 0.5.1279 rather than 0.5.1278
0.5.1278 was already published on
mainfor a stretch of commits. Re-using it would mean two different trees carrying the same patch version, which is worse than the gap. Skipping to 0.5.1279 leaves 1278 burned and moves forward cleanly.What this is not
This is not a routine bump, so it does not conflict with the contributor rule in
CLAUDE.mdthat says outside PRs should leave the version alone. That rule exists to stop in-flight PRs colliding on the patch number — which is precisely the failure being repaired here. The version line is the entire content of this PR.The underlying cause is worth a separate look: nothing currently prevents a merge from lowering the version. A check comparing the incoming
**Current Version:**against the one onmainwould have caught this at PR time, and would also have caught it on any of the five PRs that inherited it.Validation
Ran:
cargo update --workspaceto refreshCargo.lock(version lines only — the workspace crates move 0.5.1277 → 0.5.1279, no dependency changes), andcargo metadatato confirm the workspace still resolves.Did not run: the full test suite or a release build. This change touches three metadata files and no source, so there is nothing behavioral to exercise.
Note on CI:
lintis currently red onmainfor reasons unrelated to this PR — it fails at "Audit workspace architecture", and the 2000-line file-size gate is separately red for 16 files. Both predate this change.Summary by CodeRabbit