(Optionally) restrict breaking changes to explicitly mentioned crates in workspace

[hds]

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 tonic is a breaking change in 2 crates, but not in the 3rd. When this happens, we need to manually edit the version and changelog for the tokio-console crate, which shouldn't announce the breaking change.

See this comment on tokio-rs/console#557 for an example:
tokio-rs/console#557 (comment)

• Would you like to implement this feature? maybe (owing to time)

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-a and crate-b, the following commit:

feat(crate-a)!: remove deprecated function

would only be considered breaking for crate-a, even if some files in crate-b are touched in the same commit.

Using the commit footer, it could be applied as:

BREAKING CHANGE(crate-a): some function that was already deprecated has been removed.

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 tonic and tonic-build if 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.

[MarcoIeni]

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 (tests folder 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 (eg feat(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_packages
• conventional_scope_package
• commit_scope_package (preferred)
• semver_scope_package

Wdyt?