Working on DocSpec: a 12-crate workspace (core, format reader/writer crates, a facade, CLI/HTTP crates, one non-crates.io WASM crate). Using release-please in manifest mode — separate components/tags per crate, one combined release PR. Internal deps use the standard path + version pattern.

My question is about version propagation when a low-level crate releases:

1. docspec-core goes 1.0.0 → 1.1.0
2. Dependents (docspec-json, docspec-markdown-reader, facade docspec) need their Cargo.toml version reqs bumped
3. Those bumps may trigger their own releases
4. Which then cascades to docspec-cli / docspec-http

What do established workspaces actually do here?

• Release changed crates independently, then follow up with dep-bump PRs for dependents? Or version tightly-coupled crates in lockstep?
• Is cargo-release / release-plz / release-please's cargo plugin the right tool to handle ordering + cascading bumps?
• How do you avoid stale internal dep versions while keeping crates independently versioned?

Pointers to real projects doing this well would be great

1 post - 1 participant

Read full topic