Add clear guidelines for allowed Protobuf changes

[amaury1093]

Summary

Add clear guidelines for allowed Protobuf changes

Problem Definition

App developers are not clear which changes are allowed in proto files (adding fields? removing fields? renaming fields?...).

This led for example to the SDK to add reserved fields to some proto messages (e.g. Vote), which turned out to be a PITA for proto clients.

Proposal

We should define clear guidelines on allowed Protobuf changes within the SDK context.

We currently have the buf linter as a CI check. However, SDK proto checks should be stricter than only buf. Some items that should be checked:

• Never rename fields.
• Never remove fields (even if we add a reserved keyword).
• Never add fields to Msg*s, or else the unknown field rejection will error
  • We also need to be extra careful about adding fields on structs that can be deeply nested in Msg (maybe even in Anys?), because the unknown field rejector might also error on those
• Think about gogoproto annotations: they are not proto-breaking, but might create API-breaking changes for app developers.

Meeting Notes where this was originally proposed.

Additional notes

The idea to automate this check has also been discussed, but is a nice-to-have in a future step.

---

For Admin Use

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