What happens
When a cargo workspace is in a prerelease window (a PrereleaseVersioningStrategy, e.g. prerelease: true with prereleaseType: "beta"), crates that are released directly get the correct prerelease bump (1.0.0-beta.0 → 1.0.0-beta.1).
But a crate that is only cascade-bumped - i.e. it has no release commits of its own and is force-bumped solely because it depends on a crate that is being released - gets the wrong version. Instead of incrementing the prerelease counter, it bumps the base patch and keeps the stale prerelease suffix:
1.0.0-beta.0 → 1.0.1-beta.0 ❌ (expected: 1.0.0-beta.1)
So in a single release PR you end up with two inconsistent paths:
core/* (directly released) → 1.0.0-beta.1 ✅
bindings/* (only a dependent of core) → 1.0.1-beta.0 ❌
Root cause
CargoWorkspace.bumpVersion always uses a raw PatchVersionUpdate, which is unaware of the configured versioning strategy:
src/plugins/cargo-workspace.ts
protected bumpVersion(pkg: CrateInfo): Version {
const version = Version.parse(pkg.version);
return new PatchVersionUpdate().bump(version);
}
PatchVersionUpdate.bump increments patch and carries the existing preRelease string through verbatim, which is exactly the 1.0.0-beta.0 → 1.0.1-beta.0 behavior above.
This was already fixed for node-workspace
node-workspace had the identical bug and it was fixed in #2249 (fix: support-node-workspace-plugin-prerelease, commit 88dc416) by delegating to the configured strategy instead of hard-coding a patch bump:
protected bumpVersion(pkg: Package): Version {
const version = Version.parse(pkg.version);
const strategy = this.strategiesByPath[pkg.path];
if (strategy) return strategy.versioningStrategy.bump(version, []);
return new PatchVersionUpdate().bump(version);
}
cargo-workspace already stores strategiesByPath in preconfigure(), just like node-workspace, so the same one-line delegation applies directly.
References
What happens
When a cargo workspace is in a prerelease window (a
PrereleaseVersioningStrategy, e.g.prerelease: truewithprereleaseType: "beta"), crates that are released directly get the correct prerelease bump (1.0.0-beta.0→1.0.0-beta.1).But a crate that is only cascade-bumped - i.e. it has no release commits of its own and is force-bumped solely because it depends on a crate that is being released - gets the wrong version. Instead of incrementing the prerelease counter, it bumps the base patch and keeps the stale prerelease suffix:
So in a single release PR you end up with two inconsistent paths:
core/*(directly released) →1.0.0-beta.1✅bindings/*(only a dependent ofcore) →1.0.1-beta.0❌Root cause
CargoWorkspace.bumpVersionalways uses a rawPatchVersionUpdate, which is unaware of the configured versioning strategy:src/plugins/cargo-workspace.ts
PatchVersionUpdate.bumpincrementspatchand carries the existingpreReleasestring through verbatim, which is exactly the1.0.0-beta.0→1.0.1-beta.0behavior above.This was already fixed for node-workspace
node-workspacehad the identical bug and it was fixed in #2249 (fix: support-node-workspace-plugin-prerelease, commit88dc416) by delegating to the configured strategy instead of hard-coding a patch bump:cargo-workspacealready storesstrategiesByPathinpreconfigure(), just likenode-workspace, so the same one-line delegation applies directly.References
88dc416)