chore(release): version crates independently to fix release-plz resolution#223
Merged
Merged
Conversation
Coverage Report for CI Build 26343067504Coverage increased (+0.03%) to 94.822%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
…ution Shared workspace versioning (`version.workspace = true`) breaks release-plz on any release that crosses a pre-1.0 minor boundary. The breaking `fix(core)!` change bumps the shared version to 0.2.0, which drags every crate -- including unchanged leaves like tsoracle-yieldpoint and tsoracle-openraft-toolkit -- to 0.2.0 via inheritance. release-plz only rewrites internal version requirements for crates it actually releases, and it leaves the unchanged leaves out of the release set, so their inbound `^0.1.x` pins are never rewritten. Pre-1.0 a minor bump is a breaking bump, so `^0.1.x` cannot resolve against 0.2.0 and `cargo update` fails. Versioning the 12 publishable crates independently lets unchanged crates keep their version (so their inbound pins keep resolving) while release-plz bumps and rewrites pins only for the crates that changed. Verified with release-plz 0.3.158: the workspace resolves and this release produces 0.2.0 (proto, core, server, client, driver-openraft, driver-paxos, paxos-toolkit), 0.1.5 (consensus, driver-file, tsoracle), and 0.1.4 (openraft-toolkit, yieldpoint). Note: crate versions are no longer uniform across the workspace.
SebastianThiebaud
force-pushed
the
chore/release-plz-independent-versions
branch
from
c7cb9e9 to
05ee1e4
Compare
Merged
This was referenced May 23, 2026
Merged
Merged
Closed
SebastianThiebaud
added a commit
that referenced
this pull request
May 24, 2026
* fix(proto): bump to 0.2.2 to republish the lifted leader-hint API The published tsoracle-proto 0.2.1 (from release #233) predates the leader-hint lift in #295, which added LEADER_HINT_TRAILER_KEY, LeaderHintLookup, and decode_leader_hint to v1 under a refactor: prefix. Because crates version independently and release_commits gates releases to feat/fix/perf, that change never bumped proto's version — so the crates.io 0.2.1 lacks those symbols. tsoracle-server 0.2.3 already uses them, so cargo publish --verify built the server tarball with the path dep stripped, resolved tsoracle-proto ^0.2.1 to the stale registry 0.2.1, and failed to compile (E0432/E0425), aborting the release. Bumping to 0.2.2 (patch: additive, non-breaking; all consumers pin ^0.2.1 so they resolve to it with no cascade) gets a proto containing the symbols published ahead of the dependent crates. * docs(contributing): require feat/fix for library API additions, not refactor Document the release-mechanics trap behind the proto 0.2.2 fix: adding public API to a library crate is user-visible to dependent crates even when the gRPC wire contract (the v1 proto package) is unchanged, so it must use feat:/fix: rather than refactor:, which does not trigger a release. Also correct the stale "version.workspace = true / lockstep" claim — crates have versioned independently since #223 — and spell out the release_commits prefix filter.
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
2 participants
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.
Problem
The
release-plz PRjob fails withfailed to select a version for the requirement tsoracle-yieldpoint = "^0.1.4" ... candidate versions found which didn't match: 0.2.0, aborting the release PR (example run).Root cause
Three things collide: shared workspace versioning (
version.workspace = true), the breakingfix(core)!(#221) bump that moves the shared version to0.2.0, and caret-locked internal pins (^0.1.x). release-plz only rewrites the internal version requirements of crates it actually releases; it leaves unchanged leaf crates (tsoracle-yieldpoint,tsoracle-openraft-toolkit) out of the release set, so their inbound^0.1.xpins are never rewritten — yet inheritance still drags those crates to0.2.0. Pre-1.0 a minor bump is a breaking bump, so^0.1.xcannot span0.2.0andcargo updatefails.Fix
Version the 12 publishable crates independently (drop
version.workspace = true). Unchanged crates keep their version so their inbound pins keep resolving, while release-plz bumps and rewrites pins only for the crates that changed. This is release-plz's native versioning model. Non-published members (examples, benchmarks,tsoracle-tests) keep inheriting[workspace.package].versionand are unaffected.Verification
Reproduced and validated locally with release-plz 0.3.158:
release-plz updateresolves cleanly (nocargo updatefailure,Cargo.lockupdates, inbound pins rewritten correctly), andcargo metadataparses the workspace. This release produces:0.2.0: tsoracle-proto, tsoracle-core, tsoracle-server, tsoracle-client, tsoracle-driver-openraft, tsoracle-driver-paxos, tsoracle-paxos-toolkit0.1.5: tsoracle-consensus, tsoracle-driver-file, tsoracle (bin)0.1.4: tsoracle-openraft-toolkit, tsoracle-yieldpointNote
Crate versions are no longer uniform across the workspace — each version now reflects that crate's actual change magnitude. Anyone assuming all
tsoracle-*crates share a single version should be aware this no longer holds. Committed aschore(release):so it doesn't itself trigger spurious leaf-crate bumps; the existing breaking commit already drives the0.2.0release once this lands and the release PR (#195) re-runs.