Description
openedon Sep 30, 2020
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