Release cycle lessons

[tcharding]

Last release cycle we learned that we need to have rust-miniscript ready to go when we drop rust-bitcoin releases otherwise the release is not usable by much of the ecosystem.

Based on that this release cycle I maintained a branch on rust-miniscript with the upgrade, early on however I deleted bitcoind-tests as a quick and dirty hack to save me thinking about bitcoind and rust-bitcoincore-rpc. This came back to bite us because we have spent the last few weeks waiting on these crates in order to do the rust-miniscript upgrade. Lesson learned, my fault, and please accept my apology.

As part of the next release cycle I think we should create upgrade PRs for:

1. rust-miniscript
2. bitcoind
3. rust-bitocincore-rpc
4. bdk (and associated crates)
5. rust-lightning
6. electrs

1, 4, 5, and 6 are based on #2198

(2) and (3) are used for testing. (2) is owned by @RCasatta and (3) is maintained by @stevenroose. If we are going to do all this it puts pressure on Riccardo and Steven. Should we consider adding additional maintainers (and publishers) to those crates and possibly bringing bitcoind into the rust-bitcoin organisation (see rust-bitcoin/bitcoind#149)?

[Kixunil]

We could even consider making upgrade PRs to a special brach of our forks of those crates for much faster feedback. We would immediately know if some changes are problematic and avoid things like releasing bitcoin and then having to add a new feature because we accidentally broke some use case (like with target computation recently). Also if anything improves it'd be instantly visible.

This would make CI more complicated but could be really worth it.

[dpc]

Since rust-bitcoin releases break APIs I don't think lots of projects will have time to try pre-release versions. In Fedimint we're already N dependencies far, so we can't even get 0.29 yet.

[dpc]

BTW. Patch releases and yanking previous versions are totally fine, from my PoV as a consumer.

[Kixunil]

Yeah, that's even more reason for doing this.

[dpc]

I don't understand the conclusion here. Is it "as a part/follow-up of the release of rust-bitcoin, we're try to actively prepare PRs to most commonly used dependencies, so more projects can try the new release faster"?

[yancyribbens]

It seems like a request for input, not so much a conclusion. How to move all the projects in lock step more efficiency? Adding more maintainers could add more burden than increase efficiency of the projects listed above unless there are already people up to speed on the project.

[Kixunil]

Probably not a conclusion but I think that's the intention. And it makes sense.

[tcharding]

I guess I was raising a orthogonal issues:

1. Crates we (as rust-bitcoin maintainers) control hold up other crates from using rust-bitcoin releases (rust-miniscript, bitcoind, rust-bitcoincore-rpc).
2. Recent rust-bitcoin releases have been unusable by major projects (0.30 by LDK, and by extension Fedimint)

The original suggested "solution" was to do upgrades ourselves because like mentioned, the major projects are busy enough already without testing our stuff. I was not trying to force others to upgrade, just trying to help them but also ensure we are doing our job correctly.

[dpc]

Yeah. Any updates need to propagate through the ecosystem, and for a non-trivial Bitcoin application, one needs to pull in quite a few of these. rust-bitcoin, miniscript, bitcoincore-rpc.

Would be great to either manually or automatically figure out which dependents of rust-bitcoin have most dependents to have a sorted list. I see that this site has number of downloads which might be a good first approximation.

[tcharding]

Perhaps a list of crates and the upgrade graph, required to upgrade the PSU (Prototypical Set of Users, #2198).