Review cargo-smart-release safety bumping feature

[Byron]

Even though it generally works, it won't correctly figure out which crates to release in the light of a safety bump, nor does it correctly bump about-to-be-released crates that are safety bumped themselves.

To reproduce:

• add a breaking change in git-hash
• add any non-breaking change in git-repository
• try to release git-repository

Even though it will call out a lot of safety bumps, it will fail to:

• minor bump git-repository even though it should be affected by the safety bump caused by git-hash
• release all crates that have been minor-bumped as triggered by git-hash that are in the dependency chain of git-repository

The above would cause publish failure as git-repository depends on safety-bumped version of its dependencies which have not been published yet.

Getting this right probably meant to alter how the dependency processing works a lot, it appears the dependency-checking should have access to the safety-bumped crates, instead it only looks at changes in the git-history. Alternatively, the skipped-crates could be picked up again by the safety bumping, allowing them to be re-added now that a bump is desired and they were determined to be in the dependency chain of about-to-be-published crates.

Probably the cause of #221, which is downstream breakage due to safety bumps not being applied even though they should have.

Tasks

• the fix
• order of crates is wrong if breaking-safety bumps are inserted. Need to reorder according to dependency order somehow or the publish will fail.
• unchanged crates that are marked for publishing might not actually be published and it fails to recognize breaking changes should publish it. Or am I getting this wrong?
• forced releases are possible now, meaning that there is no change but a breaking change is happening in dependencies. This could be fixed by doing a separate commit for changelogs after manifest updates, always giving them one commit. Or such an update could just be handled specifically. - it's really about it refusing to publish unchanged crates despite them seeing breaking changes. It's about dependency breaking change resolution.
• it's still possible to have breaking changes affect a crate that should be published, but it won't be published as it had no changes originally. It's about resolution - seems to work now.
• smart-release cargo-smart-release gitoxide refuses to release gitoxide, even though cargo smart-release wants to to it just fine.
• publish result seems dependent on input package order, see gitoxide cargo-smart-release vs the inverse.

[Byron]

@epage I remember you mentioning a shared dependency engine of sorts and after this arduous rewrite of exactly that it's now a step closer to being possible.

• traverse.rs
  • analyse the dependency graph and produce a flat list of data about each crate in publishable order (even if many items in the list won't actually be published)
• present_dependencies()
  • takes the data from above and makes it understandable to the user
  • potentially abort if some invariant isn't met
• manifest and changelog adjustments
  • after presenting, most of the work is done there to ultimately adjust all manifests and changelogs

Now the same data structure is used by the changelog subcommand so it knows exactly which crates will be published, and hence need changelogs generated. After a lot of back and forth and polishing I finally feel good about the logic in there (as in: a human being can understand it), so I'd be glad to hear what you think if you have the time.