Summary
hiroz-msgs's dependency on hiroz (crates/hiroz-msgs/Cargo.toml) carries a hardcoded version = "0.2" literal. This is required for cargo publish to accept a path dependency, but it does not derive from [workspace.package] version. It needs a manual bump alongside every future workspace version bump, or the published crate's manifest silently keeps a stale minimum version while path-based (in-workspace) builds keep working unaffected — the discrepancy stays invisible locally.
Where this literal lives today
| Location |
Kept in sync by |
[workspace.package] version (Cargo.toml) |
The source of truth for the workspace's own version |
[workspace.dependencies] entries for hiroz, hiroz-codegen, hiroz-protocol, rmw-zenoh-rs |
Nothing — each is a separate literal, currently "0.2.0" |
crates/hiroz-msgs/Cargo.toml's hiroz dependency |
Nothing — a third separate literal, "0.2" |
docs/user-guide/custom-messages.md's example Cargo.toml |
Nothing — a fourth separate literal, external to the workspace by necessity |
hiroz-derive's equivalent literal was consolidated with hiroz-msgs = { workspace = true, optional = true } (referencing [workspace.dependencies] directly). hiroz itself could not take the same fix: Cargo does not currently support overriding default-features on a workspace = true dependency, and hiroz-msgs needs default-features = false, features = ["rmw-zenoh"] on hiroz. So hiroz's copy stays a fourth independent literal.
How another project in this dependency graph handles the same problem
eclipse-zenoh/zenoh has the identical structure: every internal crate is declared once in [workspace.dependencies] with an explicit exact-pin version (e.g. zenoh-buffers = { version = "=1.9.0", path = "commons/zenoh-buffers", default-features = false }), and member crates consume it via { workspace = true, features = [...] }. The version literal itself does not derive from anything either — it's the same manual-literal shape hiroz has.
What differs is that zenoh's release workflow calls eclipse-zenoh/ci/bump-crates@main on every release, which rewrites every [workspace.dependencies] version literal across the whole workspace automatically, matched by a regex over the internal crate names. Nobody hand-edits those version strings.
Proposal
Adopt an equivalent automated bump step in hiroz's own release process, so every [workspace.dependencies] version literal (and any crate-local copies that can't use workspace = true, like hiroz-msgs's hiroz dependency) gets rewritten together whenever the workspace version bumps — instead of relying on someone remembering to grep for the old version string by hand.
Not a code change in itself
No specific implementation is proposed here — this is a decision about whether to invest in release automation, not a patch. Worth deciding: build something zenoh-ci-shaped, or a narrower workspace-local script that only needs to handle hiroz's own crate list.
Summary
hiroz-msgs's dependency onhiroz(crates/hiroz-msgs/Cargo.toml) carries a hardcodedversion = "0.2"literal. This is required forcargo publishto accept a path dependency, but it does not derive from[workspace.package] version. It needs a manual bump alongside every future workspace version bump, or the published crate's manifest silently keeps a stale minimum version while path-based (in-workspace) builds keep working unaffected — the discrepancy stays invisible locally.Where this literal lives today
[workspace.package] version(Cargo.toml)[workspace.dependencies]entries forhiroz,hiroz-codegen,hiroz-protocol,rmw-zenoh-rs"0.2.0"crates/hiroz-msgs/Cargo.toml'shirozdependency"0.2"docs/user-guide/custom-messages.md's exampleCargo.tomlhiroz-derive's equivalent literal was consolidated withhiroz-msgs = { workspace = true, optional = true }(referencing[workspace.dependencies]directly).hirozitself could not take the same fix: Cargo does not currently support overridingdefault-featureson aworkspace = truedependency, andhiroz-msgsneedsdefault-features = false, features = ["rmw-zenoh"]onhiroz. Sohiroz's copy stays a fourth independent literal.How another project in this dependency graph handles the same problem
eclipse-zenoh/zenohhas the identical structure: every internal crate is declared once in[workspace.dependencies]with an explicit exact-pin version (e.g.zenoh-buffers = { version = "=1.9.0", path = "commons/zenoh-buffers", default-features = false }), and member crates consume it via{ workspace = true, features = [...] }. The version literal itself does not derive from anything either — it's the same manual-literal shape hiroz has.What differs is that zenoh's release workflow calls
eclipse-zenoh/ci/bump-crates@mainon every release, which rewrites every[workspace.dependencies]version literal across the whole workspace automatically, matched by a regex over the internal crate names. Nobody hand-edits those version strings.Proposal
Adopt an equivalent automated bump step in hiroz's own release process, so every
[workspace.dependencies]version literal (and any crate-local copies that can't useworkspace = true, likehiroz-msgs'shirozdependency) gets rewritten together whenever the workspace version bumps — instead of relying on someone remembering to grep for the old version string by hand.Not a code change in itself
No specific implementation is proposed here — this is a decision about whether to invest in release automation, not a patch. Worth deciding: build something zenoh-ci-shaped, or a narrower workspace-local script that only needs to handle hiroz's own crate list.