Bump group to v1 (and maybe gov too)

[amaury1093]

Summary

Bump group from v1beta1 to v1

Problem Definition

It seems that we are stuck at v1beta* even for some pretty stable APIs (because of fear of commitment?). Maybe it's time to take the leap to v1.

Proposal

Bump group from v1beta1 to v1.

Questions

• We mentioned that we wanted automatic execution on voting period end in group, but because of fee payment, we postponed that to later. If we bump group to v1 now, can this be added while keeping group at v1?
• what about gov? v1 too? Or wait for a deposit module or full gov/group alignment before v1?
  • (my preference: gov stays v1beta2 because of MsgDeposit, which could go in x/deposit. Also, now, gov proposal tallying and execution are free, which doesn't seem ideal).

---

For Admin Use

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

[webmaster128]

One thing we realized with the v1beta1 modules is that once they are out there, we have a hard time breaking them again. So let's keep it simple and go for v1, v2, v3, v4, … Nobody is assuming a v1 is perfect.

[aaronc]

My main restraint around v1 is that a lot of modules will still depend n v1beta1 types like Coin. But I think v1beta1 will effectively stay around forever. So let's not release any more beta packages into production. From now on, probably everything new should be v1, v2, etc. once it hits production. alpha and beta are really for pre-release testing

[amaury1093]

There was discussion to bump Coin to v1, right? Why don't we do that? Then gov and group can both be at v1, without depending on too much v1beta1 stuff.

If we do that, I'd feel comfortable bumping both to v1.

[aaronc]

There was discussion to bump Coin to v1, right? Why don't we do that? Then gov and group can both be at v1, without depending on too much v1beta1 stuff.

If we do that, I'd feel comfortable bumping both to v1.

Sure, but then we'll have two different coin types. Or we can just move all coins to v1 across the SDK. If we do that, I request cosmos.coins.v1.Coin instead of cosmos.base and please let's not move DecCoin or anything else because I consider the current Dec encoding buggy.

[amaury1093]

Sure, but then we'll have two different coin types. Or we can just move all coins to v1 across the SDK.

If we move all coins to v1, then we need to bump all proto packages too. So basically we have the solutions:

1. Bump coin to v1, and bump all proto packages to v1. Radical change, but maybe that's good.
2. Bump coin to v1, only bump gov&group to v1. We have 2 coin types, we might need a ConvertToV1Coin/ConvertToV1beta1Coin if there are inter-module calls.
3. Bump gov&group to v1, keep coin at v1beta1.

2 seems messy. 1 is maybe okay, but needs a ton of work if we want to support both v1beta1 and v1 (like we do in gov), 1 seems like Framework WG scope.

So I would say 3/. Also seems like we're always circling back to this solution 🤷 Does that sound good @aaronc ?

[webmaster128]

I'm fine having some v1beta1 types around for a long time, maybe forever. If you think of developers importing types in their IDE by just typing "Coin", I see an advantage of avoiding a type duplication.

But who knows, maybe there will be a Coin successor at some point.

All of the proposed options have their advantages and disadvantages but at the end of the day, I would also go with 3.