tendermint-rs versioning strategy and support for multiple versions of Tendermint

[thanethomson]

At present, tendermint-rs aims to support the latest official release of Tendermint. The trouble is, this version will sometimes be out of sync with the version employed by Cosmos/Gaia (and possibly other chains).

It seems as though we're going to ideally need to support:

• The latest version of Tendermint (e.g. v0.35.x)
• The version of Tendermint used by Cosmos/Gaia (sometimes a little behind the latest version of Tendermint, as is currently the case since it uses v0.34.x)
• The current pre-release version of Tendermint to test out new features (e.g. v0.36.x-dev)

We've considered a variety of versioning and VCS approaches, and it looks like the lowest-maintenance one would be to maintain two sets of crates:

• tendermint* crates for compatibility with the latest versions of Tendermint
  • We'll create a v0.23.x branch that will maintain compatibility with Tendermint v0.34.x (currently used by Gaia). This will allow us to release v0.23.x patch versions of the tendermint* crates, which may or may not contain breaking changes, so users should pin to a very specific version of the v0.23.x release series to avoid accidentally pulling in breaking changes.
  • master will target the latest official release of Tendermint (currently v0.35.x). Our release train here will continue as normal (i.e. the next release will be v0.24.0, which will target Tendermint v0.35.x).
• tendermint-dev* crates for compatibility with the upcoming pre-releases of Tendermint (e.g. v0.36.x-dev). Work here will take place on a dev branch.

@xla, @hdevalence, @tony-iqlusion, feel free to weigh in here on this strategy. Right now we feel like it's the lesser of many possible evils 🙂

[soareschen]

I feel that the current approach for multi-branch development for tendermint-rs is unmaintainable. By just trying to merge v0.23.x with master, there are so many conflicts with minor insignificant changes that does not warrant of why they should be different between the two branches.

Right now my PR #1071 is stuck in limbo, since it involves moving files containing conflict around. The conflicts are so non-obvious that the only possible way to go forward is to rework the entire PR from scratch. And I am hesitating to do that as even if I do so, it will only cause further issue on how to reconcile the PR back from 0.23.x back to master. So I am leaving it dormant until this issue is resolved.

I think we should have a meeting to discuss how to better approach the development for tendermint-rs. IMO having multi-branch development is ok only if the active branches are regularly synced through merging with master. Any conflict between the branches should only result from breaking changes. Cherry-picking changes would only result in minor inconsistencies accumulating and make it impossible to tell which conflicts are breaking and which one are minor.

I also think that the master branch for tendermint-rs should have the same version used by ibc-rs. Or put it in another way, both ibc-rs and tendermint-rs should agree on the official mainline version of Tendermint to be used. If there are changes to tendermint-rs related to future versions of tendermint, they should be the one that being put in separate branch and not stay on master.

New version-agnostic changes to tendermint-rs should always be made to master, and the other branches should regularly merge from master to incorporate those changes. Any version-specific changes should be resolved in the merge commit or the branch-specific commit, so that once they are resolved, merging from master the next time is straightforward it the changes are not in conflict with the version-specific changes.

[thanethomson]

I feel that the current approach for multi-branch development for tendermint-rs is unmaintainable. By just trying to merge v0.23.x with master, there are so many conflicts with minor insignificant changes that does not warrant of why they should be different between the two branches.

The v0.23.x branch will never be merged with master. When Gaia upgrades to Tendermint v0.35 (see https://github.com/cosmos/gaia/blob/main/docs/roadmap/cosmos-hub-roadmap-2.0.md#theta-upgrade-expected-q1-2022) then ibc-rs will have to switch to using master and the v0.23.x branch will be deprecated and eventually deleted.

Right now the heuristic you should be using when contributing to tendermint-rs is:

1. Look at the tendermint-rs versioning table in the readme and choose which version of Tendermint you need to support right now. In your case, that would be Tendermint v0.34.x because ibc-rs still targets compatibility with Tendermint v0.34.x, and will continue to do so until Gaia upgrades to Tendermint v0.35.x.
2. Submit your PR against the relevant branch (i.e. v0.23.x).
3. If you want your change to make it into the v0.24 series of tendermint-rs (currently on master), add it to the backport tracking issue here: meta: Backport tracking #1033 - then work on a separate PR to make the requisite changes to master.

IMO having multi-branch development is ok only if the active branches are regularly synced through merging with master. Any conflict between the branches should only result from breaking changes. Cherry-picking changes would only result in minor inconsistencies accumulating and make it impossible to tell which conflicts are breaking and which one are minor.

How does this solve our current problem where the version of Tendermint Core used by Gaia lags the latest released version of Tendermint Core by 3-6 months, and there could be substantial breaking changes between the two versions of Tendermint Core we have to support? Inevitably we have to employ a branching strategy in tendermint-rs that supports:

1. The latest version of Tendermint to be able to anticipate upcoming breaking changes.
2. The current version of Gaia, with which ibc-rs must be compatible.

I also think that the master branch for tendermint-rs should have the same version used by ibc-rs. Or put it in another way, both ibc-rs and tendermint-rs should agree on the official mainline version of Tendermint to be used. If there are changes to tendermint-rs related to future versions of tendermint, they should be the one that being put in separate branch and not stay on master.

That assumes that Gaia is using the latest version of Tendermint, which is not the case.

Important to note: this problem is not going to go away any time soon. As long as Gaia's version of Tendermint Core lags the latest release on the order of several months, we will need an appropriate "multi-master" branching strategy for tendermint-rs that practically caters to this reality.