fix(proto): bump to 0.2.2 to unblock the stalled release#302
Merged
Conversation
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.
…efactor 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.
Coverage Report for CI Build 26370056716Coverage remained the same at 94.913%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
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.
Why
Release run 26369479219 failed at
cargo publish --verifyfortsoracle-server 0.2.3:Root cause: #295 lifted
LEADER_HINT_TRAILER_KEY,LeaderHintLookup, anddecode_leader_hintintotsoracle_proto::v1under arefactor:prefix. Crates version independently andrelease_commits = "^(feat|fix|perf)", sorefactor:did not trigger a release — proto stayed at0.2.1, and the published0.2.1(from release #233) predates and lacks those symbols.tsoracle-server 0.2.3already uses them, so the verify build — which strips the path dep and resolvestsoracle-proto ^0.2.1from the registry — got the stale crate and failed to compile.What
tsoracle-proto→0.2.2(patch: additive, non-breaking). All consumers pin^0.2.1, so they resolve to0.2.2with no cascade. Once this lands onmain, thereleasejob publishesproto 0.2.2ahead of the stuck dependents (server 0.2.3,client 0.2.2, …), which then verify against a proto that has the symbols.CONTRIBUTING.md— document the trap (library-crate API additions must befeat:/fix:, neverrefactor:, because the API is visible to dependent crates even when thev1wire contract is unchanged), correct the stale "versions move in lockstep" claim (independent since chore(release): version crates independently to fix release-plz resolution #223), and spell out therelease_commitsprefix filter.Notes
releasejob publishes on a version-vs-registry diff, so the bump republishes regardless of this PR's squash prefix.releasejob does not regenerate changelogs, sotsoracle-proto'sCHANGELOG.mdwill have a gap at0.2.2— left as-is rather than hand-editing it.semver_check = trueso the Release PR flags "dependent uses a symbol absent from the published dep."