chore: drive release-please version bumps from inline markers - #159
Merged
Merged
Conversation
release-please bumped every workspace crate's version in Cargo.toml but never touched Cargo.lock, so the lockfile went stale on each release (main carried 0.7.1 entries against a 0.7.2 manifest until the next cargo invocation happened to rewrite it). Nothing caught it because CI ran without --locked. The release PR now also rewrites the lock entries: a TOML extra-file whose JSONPath selects every `[[package]]` without a `source`, which is exactly the set of workspace members (registry and VCS dependencies all carry one). The check job runs `cargo check --locked`, so a stale lockfile fails CI instead of silently regenerating. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Seven JSONPath entries in release-please-config.json existed only to keep the internal `[workspace.dependencies]` version pins in step with the workspace version. A new crate had to be remembered in that file or its pin would be left behind. Dropping the pins is not an option: cargo (1.92 and stable 1.98 alike) refuses to package a path dependency without a version. Each of the eight lines now ends with `# x-release-please-version`, and the config has a single `generic` entry for Cargo.toml. The marker sits on the line it governs, so a new crate's entry is a copy of its neighbour. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Claude finished @alukach's task in 1m 19s —— View job Review complete
✅ No blocking issues — safe to merge. Verified the mechanics:
Nothing else in the diff touches code paths, dependencies, or CI permissions. Simplify (ponytail) — none. This PR is itself the simplification (7 JSONPath entries → 1 generic entry); no new abstractions, dependencies, or boilerplate introduced. 💰 Estimated review cost: $0.23 · 1m19s · 13 turns |
The previous commit's manifest was produced by a local release simulation and seven dependency pins were not reset to 0.7.2, which breaks resolution (path crates are 0.7.2). Squash on merge. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
🚀 Latest commit deployed to https://multistore-proxy-pr-159.development-seed.workers.dev
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What I'm changing
release-please-config.jsoncarried seven separate JSONPath entries, one per internal crate, just to keep theversionpins under[workspace.dependencies]in step with the workspace version. Adding a crate meant remembering to add an eighth entry in a file nowhere near the manifest; forgetting it leaves the new crate's pin behind at the old version, whichcargo publishthen rejects or, worse, resolves to a stale release from crates.io.I first tried dropping the pins entirely, since every member uses
version.workspace = true. Cargo does not allow that: both 1.92 and stable 1.98 refuse to package a path dependency without aversion("all dependencies must have a version requirement specified when packaging"). So the pins stay, and the config is collapsed instead.Stacked on #158 (both PRs edit the same
extra-filesarray).How I did it
Cargo.toml: each of the eight lines release-please must bump ([workspace.package] versionplus the seven internal pins) ends with# x-release-please-version. The marker sits on the line it governs, so a new crate's entry is a copy of its neighbor and cannot be forgotten in a separate file.release-please-config.json: the seventoml/JSONPath entries forCargo.tomlbecome a single{"type": "generic", "path": "Cargo.toml"}entry. The generic updater replaces the first semver-looking string on any line carrying the marker and leaves every other line untouched, includingrust-versiononce chore: adopt workspace lints, declare MSRV, lint Workers crates in CI #154 lands (no marker there).CONTRIBUTING.md: one paragraph on adding a workspace crate: pin the version (cargo requires it) and add the marker..github/workflows/release.ymlis unchanged. Itssedthat re-pins from the tag on publish still matches these lines and remains a useful belt-and-braces for tag-driven pre-releases.Verified with release-please's actual
Genericupdater (v17.9.0) run against this manifest: exactly the eight marked lines change,cargo metadatastill parses the file, andcargo check --lockedpasses after applying both updaters at a simulated 0.7.3.Test plan
Genericupdater dry run: 8 lines changed, all marked, nothing elsecargo metadata --no-depson the annotated manifestcargo check --lockedbefore and after a simulated release bump through both updaters🤖 Generated with Claude Code