split protos into tendermint and spec

This commit is contained in:
Callum Waters
2022-02-11 16:29:42 +01:00
parent 418f99f716
commit 2d62b5a3d2
19 changed files with 9 additions and 17 deletions
+1 -8
View File
@@ -47,13 +47,7 @@ test/fuzz/**/corpus
test/fuzz/**/crashers
test/fuzz/**/suppressions
test/fuzz/**/*.zip
proto/tendermint/blocksync/types.proto
proto/tendermint/consensus/types.proto
proto/tendermint/mempool/*.proto
proto/tendermint/p2p/*.proto
proto/tendermint/statesync/*.proto
proto/tendermint/types/*.proto
proto/tendermint/version/*.proto
proto/spec/**/*.pb.go
*.aux
*.bbl
*.blg
@@ -61,4 +55,3 @@ proto/tendermint/version/*.proto
*.pdf
*.gz
*.dvi
*.pb.go
+8 -9
View File
@@ -1,8 +1,13 @@
# Protocol Buffers
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.
This sections defines the protocol buffers used in Tendermint. This is split into two directories: `spec`, the types required for all implementations and `tendermint`, a set of types internal to the Go implementation. All generated go code is also stored in `tendermint`.
More descriptions of the data structures are located in the spec directory as follows:
## Process of Updates
- [Block](../spec/core/data_structures.md)
- [ABCI](../spec/abci/README.md)
- [P2P](../spec/p2p/messages/README.md)
## Process to generate protos
The `.proto` files within this section are core to the protocol and updates must be treated as such.
@@ -14,10 +19,4 @@ The `.proto` files within this section are core to the protocol and updates must
1b. Merge the RFC.
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).
3. Open issues within Tendermint-go and Tendermint-rs repos. This is used to notify the teams that a change occurred in the spec.
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.
### Versioning
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.
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.
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.