Exclude unchanged crates from a release

[tonyg]

Maintainer's notes:

• Considerations for "unchanged":
  • If it has any changes
  • If it has [[bin]] and the lock file changed
  • If it depends on something being released and the dependency will no longer be compatible (pinned dependency with =, major version changed)
    • This needs to be calculated recursively

---

PR #296 adds a new flag, --exclude-unchanged, that filters the pkgs list (after applying --package, --exclude etc.) to include only those packages that have changed since the last tagged release, plus their transitive dependencies. It uses the existing change-detection logic, and only marks a package "unchanged" if the code would have reached the existing "Updating {} to {} despite no changes made since tag {}" warning.

[epage]

Not a fan of the flag name but I wonder if we should actually make this the default behavior.

If we make it a default or depending on how we expose this. one question is what to do with package selection flags. --package and --exclude could modify the changed rather than the default set. A couple small changed from clap-cargo might make that easier. --workspace could mean "changed members of workspace". --all is generally a synonym for --workspace but here it might be confusing. I wonder if we should remove it.

How should we handle the lock file? My guess is we should mark everything changed but let people know which ones were only because of the lock file.

If we are making decisions on the users behalf, should we make the change detection more accurate? We can use cargo package --list to see what files would be included in a package (either didn't exist or didn't know about it at the time we did this work)

[epage]

I'm thinking we should at least make this advisory at first as we test out the logic. For example, a corner case I just thought of is we need to be checking if a dependency has changed since the current crate last released and not since the dependency changed since its last release. People can release individual crates for various reasons and we need to account for this.

There are also a lot of dependency releases that don't impact their dependents. As we make this more automatic, we should probably be working to provide the user more information, like what the relevant commit summaries were. The challenge will be organizing all of the data to not overwhelm the user.

[epage]

Hmm, maybe we shouldn't consider changes from outside the current run. If someone decided not to make a release, it means they will keep having to make that decision each run.

[epage]

Lock files should only impact a crate if it has a [[bin]]. We should be able to look that up from the cargo-metadata.

[epage]

A way we can narrow down transitive changes is if extract the change detection logic in update_dependent_versions to tell us what dependents will need to be changed. We can then mark only those as changed, rather than all.

This effectively means that a dependent will only be marked changed if we are doing a breaking change. Otherwise, newly generated lock files will pick up the change "for free".