Streamline the release process

[seanchen1991]

Feature Summary

The current ibc-rs release process is error-prone and flaky, especially on the cargo release step. This is in large part due to the 30-crate rate limit for existing sub-crates; ibc-rs now has more than that in its workspace. This requires us to first manually release leaf dependencies until we meet the 30-crate limit.

Additionally, with the most recent 0.53.0 release, the ibc-testkit crate failed to be published due to it depending on the ibc-client-tendermint-cw crate, however, this crate was excluded from publishing to crates.io. The rest of the sub-crates were successfully published, but these last two crates needed to be published manually in order to complete the release.

Proposal

@romac suggested asking the crates.io maintainers about whether they can raise the 30 crate rate limit for ibc-rs. Are there perhaps other ways to get around this issue that we could look into?

[seanchen1991]

Update: Sent an email to the crates.io team, their response was:

the rate limit for releasing new versions of existing crates is a lot higher, so I expect that you shouldn't hit the rate limit anymore in the near future. If you plan to release a larger number of new crates let us know in advance and we can temporarily increase the limit.

So one possible way to address the rate limit when performing a release with new sub-crates is to email the crates.io folks so that they can temporarily increase the limit. However, this is not really an ideal solution if it needs to be done on every new release.

[romac]

How many _new_ crates were you guys trying to release last time?

[seanchen1991]

Just one, though it brought the total number of crates being published to 31. So that is a little confusing as far as why we hit the rate limit.

[seanchen1991]

Looking at it more closely, I'm not actually sure how we got this error now:

error: attempting to publish 31 existing crates which is above the crates.io rate limit

I don't actually see it in any of the CI runs in the commit history. The errors that caused the runs to fail were that we tried to publish a crate that was already published, and we had a dependency version mismatch.

So maybe the crates.io rate limit isn't causing us issues.

[rnbguy]

Hey @seanchen1991, the error is here
https://github.com/cosmos/ibc-rs/actions/runs/9069593171/job/24919695749#step:5:17

I think it was on the deleted tag - so you don't see it anymore on the commit history.

The error is from cargo-release because they hard-coded the rate limit for existing crates at 30 for a static check.

ref. crate-ci/cargo-release#483

[seanchen1991]

So it looks like there are multiple layers to the issue here as far as the rate limit is concerned. If we're publishing more than 30 existing crates, we'll hit both the crates.io rate limit as well as this check in cargo-release.

We can ask the crates.io team to temporarily raise the 30 crate limit prior to performing a new release, which isn't great, but that also won't address the check in cargo-release.

[rnbguy]

crate-ci/cargo-release#792 is now merged. We can update our release process with rate-limit configuration.

We can add the following lines in our Cargo.toml.

[workspace.metadata.release]
rate-limit = { existing-packages = 40 }

Also, we need to update our RELEASES.md to reflect this.