Summary

Cosmos SDK has been pre-1.0 for a long time and it's probably about time to at least start that conversation. This issue proposes a definition for what v1.0 would mean and how we might get there.

Problem Definition

v1.0 for me indicates that things will be stable for an appreciable amount of time. The Cosmos SDK has understandably been under a lot of flux, as has Tendermint Core. With the introduction of protocol buffers in v0.40 and in particular its support for backwards compatibility via schema evolution and breaking change detection.

Here's in my mind what would define v1.0 readiness: a version of the SDK which we can commit to that allows app, module and client developers to use v1.X versions without breaking changes to their code while still receiving upgrades for a meaningful length of time (probably > 1yr).

Proposal

Here's my proposal for how we get there.

Stable v1 protobuf packages

For v0.40 we marked almost all protobuf packages as v1beta1. In the near future after Stargate we want to migrate these all to v1 and enable breaking change detection as a required CI check. We postponed jumping for v1 right away because major changes might still be needed for large pieces. For instance #7242 came in quite late in the game and we may want to give #7122 some consideration.

Stabilization of v1 proto packages can happen one package at a time and as soon as that is reached, this gives stability for client developers.

Stable AppModule interfaces

AppModule underwent a lot of flux in v0.40. It is still a mixture of legacy amino and newer protobuf methods and I think there are ways it could greatly be simplified. Arriving at a stable set of AppModule interfaces will bring some stability for module developers. Although module dependencies like x/bank or x/staking still need to be addressed.

We could consider creating a nested go module cosmos-sdk/base or core that reaches v1.0 before the other pieces and just stabilizes AppModule and other "core" pieces.

Stable Modules

Beyond stable v1 proto definitions (covered above), module stability to me primarily means stable backwards compatible Keeper interfaces, NewKeeper constructors, and other module specific wiring. This would bring stability to app and **module developers.

Approach 1) separately versioned modules

One approach to stabilizing modules is to separate them out into separate go modules within this repository. This could allow us to stabilize other pieces like AppModule interfaces and baseapp in base or core modules. Then individual modules could be separately versioned and reach their own v1.0 on their own time frame. One big challenge with this approach is the reliance on simapp for testing. If we had simpler AppModule interfaces and the overall wiring up of apps were easier, it would be more feasible for each module to setup its own minimal simapp-like test harness that just includes the required modules it needs for testing. This requires some research though.

Approach 2) consider alternate keeper <-> keeper wiring (#7093)

#7093 (along with #7122) proposes an alternate approach to wiring keepers together that uses protobuf to define what is sent between keepers and also would give us proper Ocaps in the SDK. With this approach one module would just depend on another module's proto definitions rather than the module implementation itself. Because we're aiming for stability of the proto definitions sooner this might bring us to stability around modules quicker and also might help us have simpler AppModule wiring in general.

Stable BaseApp, AppModule and client wiring

This will bring stability to app developers and may largely be covered above. Generally though we want to aim for straight-forward but extensible wiring of all this stuff and I think we could improve a lot. Basically if we looked at simapp/app.go and simapp/simd and said wow that's really elegant... to me that would feel like a sign we're close to a v1.0 on that stuff.

/cc @ethanfrey @alessio @clevinson

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned