Release proto definitions v1 #9445
Comments
<!-- The default pull request template is for types feat, fix, or refactor. For other templates, add one of the following parameters to the url: - template=docs.md - template=other.md --> ## Description This ADR is to be merged as "DRAFT" status for now, as the details for the "Bumping Protobuf Package Version" section have not been sorted out yet. This ADR comes from discussion with @webmaster128 and @robert-zaremba about proto updates strategy. We decided to go for an ADR to document our decision for v0.43, and for visibility for other chains doing proto upgrades. [rendered](https://github.com/cosmos/cosmos-sdk/blob/am/adr-044-protobuf/docs/architecture/adr-044-protobuf-updates-guidelines.md) Closes: #9477 ref: #9446 ref: #9445 <!-- Add a description of the changes that this PR introduces and the files that are the most critical to review. --> --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [x] reviewed "Files changed" and left comments if necessary - [ ] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [x] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [x] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [x] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable)
|
For me the bumping path is still not well defined (within the SDK and with client libs), so my personal preference is to keep 0.44 smaller and discuss this for 0.45. |
|
Can this be done for 0.45? Otherwise we get even more changes to the v1beta1 version and nobody knows anymore what is actually available in 0.42, 0.44 and 0.45 backends. |
|
Version numbers should not be the way that clients know what is available in given backends. We will not be bumping proto versions with every release just to indicate that there is a new release. Instead we will aim to provide backwards compatible proto files with the same proto version for as many SDK versions as possible. Clients should use grpc reflection and the cosmos reflection service to understand what queries and messages are actually supported on a given backend. |
Summary
With Stargate we created proto definitions for all our modules. They are all marked as beta, but the whole ecosystem is getting to use them and expects stability.
Ref: #9182 (comment)
Problem Definition
There is an adoption and perception risk of sticking to beta release mode forever. Stargate was release few months ago and we should move forward with core module proto stability.
Proposal
Go out of beta for core proto definitions and release 1.0
For Admin Use
The text was updated successfully, but these errors were encountered: