Use separate go.mod for IBC applications

Summary

When migrating the IBC modules from the SDK into ibc-go, there was discussion around moving the IBC applications to their own repository. This was largely dismissed because it would likely create a ghost repository and we only had one IBC application at the time.

IBC applications exist at a level above core IBC. Asides from being required to abide by the IBC module interface, they largely employ logic that is isolated from core IBC. Applications are likely to change their functionality without core IBC functionality changing. Assuming the change is backwards compatible, chains may upgrade to these changes asynchronously and use these changes without relying on counterparty upgrades.

Thus, applications largely act independently of core IBC. This is unlike light clients which perform lower level actions such as proof verification and update/upgrade/misbehaviour handling. Furthermore, changes to the light client algorithm require all counterparties to upgrade to avoid breaking IBC connectivity. The expected timeline of such upgrades are on the scale of years. It seems reasonable to expect IBC light client changes to occur at a very slow and predictable pace.

Proposed Change

Use separate go.mod for each IBC application with ibc-go.

This allows independent release cycles for each ibc-go application. A breaking change to transfer won't cause a major version bump of core IBC.

Proposed Action

IBC applications are currently developed at a slow pace. Breaking changes typically require spec changes and thus the release cycle becomes predictable. After almost a year of releasing ibc-transfer, there was one breaking change which could have been released separately from core IBC.

I propose we wait to adopt separate go.mod's until we are certain they will be useful since we do not have the immediate need for such a change. Once adopted, it seems unlikely we can revert such a change. We should closely watch the SDK's adoption of this approach and act based on their feedback.

Possible Actions

Deciding whether we like this approach largely involves trying it out. I'm unsure of how best to try this out without including it in a release and without disrupting our workflow if we decide not to use it.

One possible route forward is to experiment with using a go.mod for our testing package. It definitely is not desirable that breaking changes to the testing package require breaking changes to core IBC or IBC applications. If we had a go.mod for our testing package, it is possible we could have released interchain accounts under v2.1 instead of v3.

Questions

Even if we have separate go.mod files, releases of applications still require stable usage of the other components within ibc-go. For example, lets say we are ready to release v2 of transfer, but core IBC is under going changes on the main branch that should not be released. Is it expected that core IBC should never be imported under the transfer/v2 tag? Or are we expected to maintain a separate branch for transfer releases which contains a stable core IBC?

cc @marbar3778

ref #596

For Admin Use

[x] Not duplicate issue
[x] Appropriate labels applied
[x] Appropriate contributors tagged/assigned

cosmos / ibc-go