The Tip of the SDK

[faddat]

Is your feature request related to a problem? Please describe.
The cosmos sdk is outpacing starport.

IBC isn't keeping pace with tendermint / sdk upgrades.

We need a solution that allows people to build with "the new stuff" because all the specs in the world will never accurately represent the state of software that is either yet to be written or needs to be written still

Describe the solution you'd like
I propose that we get a template app into the cosmos sdk (a starport template) and / or create a v0.46.0 template inside startport.

We should aim for this template to perpertually be in sync with the tip of the cosmos sdk.

Describe alternatives you've considered

Other than doing one-off work like we're doing with craft economy, this seems to be the best possible way to ensure that users of starport stay in sync with the cosmos sdk.

[fadeev]

It's basically the question of bandwidth. Once we have more people and time, Starport will be more in sync with the SDK. Please, don't forget, it's never about the template alone. All of the features of Starport have to be tested (some manually), 7 tutorials have to be updated and one blockchain has to be migrated to this version.

[faddat]

Oh, I'm not forgetting-- we're under the same bandwidth constraints, and the ecosystem is plagued by "the onboarding onramp of great difficulty and pain" since the SDK isn't really idiomatic go, but instead built around determinism constraints.

I'm trying to figure out how we might do it regardless.

Also, perhaps for this thing I'm working to describe here, maybe it is only about the template. I think that would be really useful to the ecosystem. Currently the best v0.46.0 template is simapp, but simapp isn't really an app. SDK docs then point users to starport as a scaffolding tool but it isn't in sync with the tip.

so I suppose the proposal is like:

Create a second template, usable with a flag, that attempts to work from the tip. Do not subject that second template to the typical starport qc including all features and 7 tutorials.

I guess you could say that this is related to #2040

An example of how this could be useful:

Such a template could be used to verify that upstream changes to sdk and ibc-go are playing well together-- automatically. (they currently aren't)

and yep, for the "current default version" all features and docs should be tested. But maybe not for this wild, fast-moving version I'm describing here.

[aljo242]

We are now prioritizing this work.

Can be followed here.

Ignite will be much more preemptive in staying in sync with SDK!