fix: switch release-please to simple type (workspace inheritance)#6
Merged
Conversation
…tance
The first release-please run failed:
Error: release-please failed: path not found in object: package.version
Root cause: release-type `rust` iterates every workspace member and writes a
literal `package.version` into each (updaters/rust/cargo-toml.js unconditionally
calls replaceTomlValue(['package','version'], ...)). examples/Cargo.toml has a
[package] table but no version key, so the path walk throws. Worse, even on
success the rust type (and the cargo-workspace plugin, which requires a literal
string version) would clobber `version = { workspace = true }` in proxy and
jito_protos with literals -- defeating workspace inheritance and creating
recurring conflicts every time we sync upstream master.
Fix: use release-type `simple`, which doesn't touch Cargo files, and drive the
updates via extra-files (verified against release-please 17.6.1):
- Cargo.toml [workspace.package] version via the generic annotation updater
(x-release-please-version), preserving inheritance -- proxy/jito_protos are
untouched.
- Cargo.lock entries via two `toml` updaters keyed by package name. Note the
jsonpath matches @.name.value (release-please's TOML parser wraps each scalar
as {start,end,value}), e.g.
$.package[?(@.name.value=='jito-shredstream-proxy')].version
simple's version.txt updater is createIfMissing:false, so no version.txt is
created. extra-files are merged for all strategies (strategies/base.js).
Simulated both updaters on the real Cargo.toml/Cargo.lock -> 0.2.14+qn.
Release-As: 0.2.14+qn
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
softalchemy
approved these changes
May 29, 2026
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.
Is this change upstreamable?
qn/*branch; no upstream PR.Summary
The release-please run (after #5 merged) failed:
Root cause:
release-type: rustiterates every workspace member and writes a literalpackage.versioninto each (updaters/rust/cargo-toml.jsunconditionally doesreplaceTomlValue(['package','version'], …)).examples/Cargo.tomlhas a[package]table but noversionkey, so the path walk throws. And even on success, the rust type (and thecargo-workspaceplugin, which requires a literal string version) would clobberversion = { workspace = true }inproxy/jito_protos— defeating workspace inheritance and causing recurring conflicts on everymastersync.Fix: use
release-type: simple(doesn't touch Cargo files) and drive updates viaextra-files:Cargo.toml[workspace.package] versionvia the generic annotation updater (x-release-please-version) — inheritance preserved,proxy/jito_protosuntouched.Cargo.lockentries via two toml updaters keyed by package name. The jsonpath matches@.name.valuebecause release-please's TOML parser wraps scalars as{start,end,value}:$.package[?(@.name.value=='jito-shredstream-proxy')].versionVerification (against installed release-please 17.6.1)
simple'sversion.txtupdater iscreateIfMissing: false→ noversion.txtcreated;extra-filesare merged for all strategies (strategies/base.jsline 184).Cargo.toml+Cargo.lock→ all three targets become0.2.14+qn; inheritance lines untouched;Cargo.lockstays consistent (socargo build --lockedpasses).+qncarried through by the default versioning strategy (unchanged from ci: add release-please versioning pipeline #5); thebuildjob's+qnguard still applies.Test plan
After merge, confirm release-please opens a
chore: release 0.2.14+qnPR whose diff bumps only the root[workspace.package] versionand the twoCargo.lockentries (notproxy/jito_protosmanifests), updatesCHANGELOG.md, and creates noversion.txt. Merging it should tagv0.2.14+qn.Note
Low Risk
Config-only change to release automation; no runtime or application code paths.
Overview
Switches release-please from
release-type: rusttosimpleso it no longer walks every workspace crate or overwriteversion = { workspace = true }in member manifests.Version bumps are driven only through
extra-files: the rootCargo.toml[workspace.package] version(generic /x-release-please-versionannotation) and thejito-shredstream-proxyandjito-protosentries inCargo.lock(toml updaters with package-name jsonpaths). The per-packagecomponenttag field is removed.Reviewed by Cursor Bugbot for commit 472da2e. Configure here.