Release/v0.29.0

[erwanor]

Description

This cuts a new release v0.29.0 based on the latest release of tendermint-rs (v0.29.0 as well) and ibc-proto-rs@v0.26.0 (pending cosmos/ibc-proto-rs#62). It is currently blocked on cutting ibc-proto-rs@v0.26.0, once this is done I will mark the PR as ready.

I don't have permissions to push to the repository, so I cannot pick a reviewer but I think this will be of interest to @plafer :)

---

PR author checklist:

• Added changelog entry, using unclog.
• Added tests.
• Linked to GitHub issue.
• Updated code comments and documentation (e.g., docs/).
• Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

• Reviewed Files changed in the GitHub PR explorer.
• Manually tested (in case integration/unit/mock tests are absent).

[plafer]

Hey @erwanor, happy to release a bit earlier than expected; however I would merge #279 in 0.29. I am hoping to be done today, optimistically merged tomorrow.

Does that work with you? If this is too big of a blocker for you, in the meantime, would using a patch in your Cargo.toml (to a commit after we have merged tendermint-rs 0.29) a possibility for you?

[erwanor]

hey @plafer, in this case this works, but if I may take the opportunity to voice a preference": it would be very helpful for crates downstream of tendermint-rs to have as granular releases as possible following tendermint-rs breaking changes, this makes the process of keeping up with upstream much more manageable. otherwise, this tends to nudge downstream consumers of ibc-* crates into onerous upgrade cycles since we're of course heavy users of its apis throughout our codebase! i would be more than happy to support the effort to accomplish this, for example by making the process of cutting releases easier, or even doing it (like for informalsystems/tendermint-rs#1267 or informalsystems/tendermint-rs#1268).

and please let me know if there are other ways i could support to make this less gnarly for you too, and thank for your work on this!! :)

[plafer]

I understand your concern, and it's a valid one. We'll investigate completely removing our dependency on tendermint in the mid to long term.

As for automating our releases, I'm very interested! If you'd like to take this on, it would be very appreciated.

Finally, we're planning to cut v0.29.0 tomorrow. This time it's more about the features that go in it rather than the process of releasing itself

[Farhad-Shabani]

Handled in #461

[erwanor]

Thanks, appreciate it! I just opened a ticket to gather requirements about that!

Re: tendermint-rs, it might be good to have lower coupling mid/long-term, but speaking for penumbra and probably a few others (looking around namada, and orga for examples) we would always have that feature on anyway (e.g. for the ics07 client, among other things), so for us that doesn't make a huge difference either.

I don't know if there's another way to work around breaking changes happening across the crate tree, but cutting frequent granular releases, in particular following a tendermint-rs release, would help us both with velocity and reducing the lift of upgrading, at least some of the time, rather than making dealing with breaking changes in both ibc-rs and tendermint-rs the default.

I've opened #463 and #462 which brings over CI improvements that @thanethomson worked on in tendermint-rs

[plafer]

we would always have that feature on anyway (e.g. for the ics07 client, among other things), so for us that doesn't make a huge difference either.

I think the difference is that only this other crate would need to be upgraded quickly after tendermint-rs, and that would make it easier for ibc-rs, as we are not always ready to release whenever tendermint-rs releases.