MarcoIeni
commented
2 weeks ago Thanks for opening this issue! I like the idea a lot. I would like this to be the default behavior, not only for breaking changes, but also for features.
E.g. Let's sat you have crate-a and crate-b at version 1.0.0.
A commit feat(crate-a): make coffe that touches both crates should bring crate-a to version 1.1.0 and crate-b to version 1.0.1.
I know it's technically a breaking change for release-plz, but it's not a huge one, so we can keep the 0.3.x release-plz version 👍
The pr for this issue should:
- [ ] explain this behavior in the docs
- [ ] add an integration test (
testsfolder of the release-plz crate) - [ ] check if the syntax
BREACKING CHANGE(crate_name)is compliant with https://www.conventionalcommits.org/en/v1.0.0/#specification. I don't think so. If that's not parsed correctly by the parser we use, don't implement this. The only way to indicate a breaking change crate should be in the scope (egfeat(crate-a).
Let's add an option in the config file in the workspace section to disable this behavior, too. By default the config option is true. Not sure about the name of the config field 🤔
Here are some options:
conventional_packagesconventional_scope_packagecommit_scope_package(preferred)semver_scope_package
Wdyt?
Motivations
In some workspace projects, introducing a beaking change in one crate may require changes in another crate, without actually constituting a breaking change in the second crate.
This is the case in Tokio Console, where updating to a breaking change of
tonicis a breaking change in 2 crates, but not in the 3rd. When this happens, we need to manually edit the version and changelog for thetokio-consolecrate, which shouldn't announce the breaking change.See this comment on tokio-rs/console#557 for an example: https://github.com/tokio-rs/console/pull/557#discussion_r1631179882
Solution
Using conventional commits, it could be possible to consider a breaking change commit only applicable to the crates which are explicitly mentioned. Given that this would likely be considered a breaking change from current bavhiour and also not always desireable, this should be only enabled via some default-false configuration option.
Then, in a workspace with 2 crates,
crate-aandcrate-b, the following commit:would only be considered breaking for
crate-a, even if some files incrate-bare touched in the same commit.Using the commit footer, it could be applied as:
Although I'm not sure if that doesn't break the footer detection.
Alternatives
Manually editing the release PR is the current approach, and it's not all that bad.
Additional context
This sort of situation is common when working with
tonicandtonic-buildif you keep a separate crate for the protobuf definition and generated Rust code. A new version or minor change may make the Rust code a breaking change, even though the gRPC interface remains compatible.