Expand changelog_include to support paths (not just crates)

[VorpalBlade]

Motivations

As documented changelog_include can be used to include other packages (very useful!) but not arbitrary paths. This would be useful to include updates to doc/src/mybinary1 (mdbook section) into crates/mybinary1 changelog. I use a virtual workspace with no top level crate.

• Would you like to implement this feature? [y/n] n

Solution

Add a new changelog_include_path setting which takes a list of paths (relative the root of the repository, or relative release_plz.toml, whichever is more suitable)

Alternatives

Manually updating the changelog. That is what I want to get away from, so no.

Additional context

[MarcoIeni]

Can ypu make an example of what this feature might work?

I.e. what's in the changelog from the path and how the final changelog looks like

[VorpalBlade]

Well, I don't have a good internal model for how release-plz does this currently, but I imagine it works like this:

For each crate:

1. Use the base path of that crate as the inclusive filter (e.g. crates/myawesomecrate/** borrowing zsh syntax where ** means "recursive glob"). This path would be the one that contains Cargo.toml
2. Find all changes (between the two git tags of interest, or after the last tag) that touches a file that the filter above matches. If so, include that commit in the change log.
3. Apply conventional commits-parser (or whatever the user has set up) to split into sections

If that mental model matches what is going on, it seems like a simple matter to extend that filter to be a list (e.g. ["crates/myawesomecrate/*", "doc/book/src/myawesomecrate"]

I don't see any needs for the changelog to say "oh but this was actually from that other path". It doesn't say "oh this was actually from this other crate" when I use changelog_include currently.

My use case is changelog for the end user binaries in a multi-crate workspace.

• I only produce github releases for the binary (but the supporting crates are also published to crates.io since the binaries are).
• The main reason to use multiple crates to begin with is to help with build times, they are not intended for public consumption. (Also I produce two related binaries, so I have two binary crates, and two separate release tracks, so that plays a part of it too.)
• Some of the relevant resources for the two binaries are in a shared mdbook, I want the "docs:" commits from that to be included in the release notes.
• It is easier for me to start out with a changelog that contains everything that could be relevant to an end user and edit it down, rather than doing the opposite.

I hope this answers your questions.