zolfa
/
tendermint
1
0
Fork 0
Code Issues 0 Pull Requests 0 Projects 0 Releases 221 Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
184 Commits
183 Branches
291 MiB
Tree: ed7fa80693
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from 'ed7fa80693'
${ noResults }
tendermint/proto/README.md

23 lines
1.9 KiB
Raw Normal View History

proto: add files (#246) Co-authored-by: Erik Grinaker <erik@interchain.berlin>
4 years ago
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
 
  1. # Protocol Buffers

  2. 

  3. This sections defines the types and messages shared across implementations. The definition of the data structures are located in the [core/data_structures](../spec/core/data_structures.md) for the core data types and ABCI definitions are located in the [ABCI](../spec/abci/README.md) section.
  4. 

  5. ## Process of Updates

  6. 

  7. The `.proto` files within this section are core to the protocol and updates must be treated as such.
  8. 

  9. ### Steps

  10. 

  11. 1. Make an issue with the proposed change.
  12.    - Within in the issue members from both the Tendermint-go and Tendermint-rs team will leave comments. If there is not consensus on the change an [RFC](../rfc/README.md) may be requested.
  13.   1a. Submission of an RFC as a pull request should be made to facilitate further discussion.
  14.   1b. Merge the RFC.
  15. 2. Make the necessary changes to the `.proto` file(s), [core data structures](../spec/core/data_structures.md) and/or [ABCI protocol](../spec/abci/apps.md).
  16. 3. Open issues within Tendermint-go and Tendermint-rs repos. This is used to notify the teams that a change occurred in the spec.
  17.    1. Tag the issue with a spec version label. This will notify the team the changed has been made on master but has not entered a release.
  18. 

  19. ### Versioning

  20. 

  21. The spec repo aims to be versioned. Once it has been versioned, updates to the protobuf files will live on master. After a certain amount of time, decided on by Tendermint-go and Tendermint-rs team leads, a release will be made on the spec repo. The spec may contain minor releases as well, depending on the implementation these changes may lead to a breaking change. If so, the implementation team should open an issue within the spec repo requiring a major release of the spec.
  22. 

  23. If the steps above were followed each implementation should have issues tagged with a spec change label. Once all issues have been completed the team should signify their readiness for release.