workspace.buildMetadata (#1022) stamps packages bumped in the main release loop. cascade.rs:121 writes new_version directly, so a package bumped only because a dependency bumped is released without the suffix.
In a workspace where core and app both carry the metadata and app depends on core, a run where only core has commits releases core@1.4.0+26.2-26.45 and app@1.4.1. A run where both have commits releases both stamped. Same config, same packages, different output depending on which one happened to be touched.
Two questions to settle before fixing, which is why this is not folded into #1028:
- Should a cascade bump carry build metadata at all? The version moved because a dependency moved, not because anything in that package changed, so the derived value may be meaningless for it.
- If it should, whose command runs? A cascade-bumped package is not in
bump_order, so its own command is never captured. Stamping it with a command captured for a different package is not obviously right either.
Whichever way it goes, the current behaviour is accidental rather than chosen.
workspace.buildMetadata(#1022) stamps packages bumped in the main release loop.cascade.rs:121writesnew_versiondirectly, so a package bumped only because a dependency bumped is released without the suffix.In a workspace where
coreandappboth carry the metadata andappdepends oncore, a run where onlycorehas commits releasescore@1.4.0+26.2-26.45andapp@1.4.1. A run where both have commits releases both stamped. Same config, same packages, different output depending on which one happened to be touched.Two questions to settle before fixing, which is why this is not folded into #1028:
bump_order, so its own command is never captured. Stamping it with a command captured for a different package is not obviously right either.Whichever way it goes, the current behaviour is accidental rather than chosen.