We should definitely be using cargo-semver-checks -- though bearing in mind that it's still very incomplete and we can't blindly trust an "ok" from it.

cargo-public-api looks pretty interesting. I like the idea of committing the public API in contrib/ or somethig and then diffing against that in CI, so that any API changes become visible (and easy to check for after-the-fact). And maybe there are lints we could run against the text file to check if e.g. all errors impl Debug and std::Error and so on. We'd have to experiment a bit to see how well it handles our feature-gating etc.

Whats the status of this one crew, do we want it in before next release? The one on bech32 has stalled.

ref: rust-bitcoin/rust-bech32#141

I'm not sure there should be rush but I want it eventually, definitely before 1.0 of any crate. Doing it sooner has the advantage of being able to auto-label PRs.

Let's just rebase #1880 and do it here, since Kix is onboard.

The history here is that we tried opening #1880 and got no reply from Kix after several weeks and were unable to move forward. So we switched to doing it in leaf crates where we didn't need Kix's approval (e.g. in rust-secp rust-bitcoin/rust-secp256k1#656 and in rust-bech32). Then in rust-bech32 we have gotten no reply from Clark for several weeks :).

For what it's worth, it's worked great in rust-secp ... but that's not worth much since the API for rust-secp never changes :).

But since Kix is online and in favor of this, I think we should just pull the trigger instead of waiting on rust-bech32.

Then in rust-bech32 we have gotten no reply from Clark for several weeks

Just to clear the respond Clark did respond, it was back waiting on @Kixunil (because of merge strategy proposed by me). No one is really at fault here.

Anyways, I'll rebase and YOLO - if there are too many teething problems we can always revert.