ADR 023 Protobuf Naming and Versioning

[aaronc]

Description

In light of #6030 and our transition to Any, we can make our protobuf names just a bit more concise without going overboard and losing descriptiveness. We can also make our file organization a bit more standard so that clients have an easier time running codegen.

---

For contributor use:

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

---

For admin use:

• Added appropriate labels to PR (ex. WIP, R4R, docs, etc)
• Reviewers assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[codecov]

Codecov Report

Merging #6083 into master will decrease coverage by 0.89%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6083      +/-   ##
==========================================
- Coverage   55.72%   54.83%   -0.90%     
==========================================
  Files         450      444       -6     
  Lines       27036    26771     -265     
==========================================
- Hits        15067    14681     -386     
- Misses      10886    11048     +162     
+ Partials     1083     1042      -41     

[clevinson]

As someone relatively new to the SDK codebase, I'm finding most of these changes to be an improvement on readability.

I get that we can avoid this being #api-breaking by making use of type aliases, but it would be nice to have an explicit strategy for whether we plan to maintain these type aliases indefinitely, or if they would get deprecated at some later point (6 months / 1 year in the future?).

Also, it would be nice to clarify whether new modules should create the corresponding type aliases for legacy naming conventions, or if that is considered necessary. In my opinion, i'd rather only include aliases where absolutely necessary (for backwards compatiblity of existing modules).

[aaronc]

I get that we can avoid this being #api-breaking by making use of type aliases, but it would be nice to have an explicit strategy for whether we plan to maintain these type aliases indefinitely, or if they would get deprecated at some later point (6 months / 1 year in the future?).

Also, it would be nice to clarify whether new modules should create the corresponding type aliases for legacy naming conventions, or if that is considered necessary. In my opinion, i'd rather only include aliases where absolutely necessary (for backwards compatiblity of existing modules).

I don't have a strong preference here. As I've said in the ADR, I think Msg just ends up being noise for the .proto files. Maybe for the SDK it makes sense. But even for the SDK, Msg has never been very descriptive for me. If we want to denote an action, why don't we use "action", "operation", or "command"? The word "message" makes me thing of email and chat. And as I noted in the ADR, maybe just using a verb suffices...

[alexanderbez]

Thanks for taking the time to write this up @aaronc. In principle, I agree with the bulk of the proposal. On the few things I don't understand or disagree with, I've commented on 👍

[alexanderbez]

I would like to get this merged. Anything I can help with @aaronc? Can you resolve any issues?

[aaronc]

@alexanderbez just updated this. Can you take a look and see if it looks good to move forward?

[alexanderbez]

ACK