New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Add "Since:" on proto doc comments #10434
Changes from 3 commits
cb3ea4a
be44209
390a416
1c8a923
f74fd81
42d543e
83a30b8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
other ideas that came up:
@since cosmos-sdk 0.43
@since github.com/cosmos/cosmos-sdk@v0.43
(but that's not actually a valid github or go module tag)@since 0.43
Opinions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out there is a bit of a collision then using the JSDoc/TSDoc style
@since
. It is represented as if it's about the JS/TS library version. See https://jsdoc.app/tags-since.html The same problem would apply for types generated in Java.I think it's better to avoid this conflict and just make it plain text for the callers, starting with
Since:
.Since: cosmos-sdk 0.43
would be my favourite. It is clean, refers to the repo name and allows us to split by whitespace when parsing.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's actually okay if we stick to strict API based versioning - the npm or maven package version would line up with the go version. I know want to have a high level user friendly package. But for individual low level proto packages I think could make a lot of sense to have own npm package per proto package with the exact same API version. Then the
@since
tag would work nicely with existing tools.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I actually don't see a lot of advantages for having the npm/maven/go/proto types versions all be the same. On the other hand, one disadvantage I see is the need to lock proto bumping speed with JS/Java/Rust bumping speed.
Simon mentioned yesterday about CosmJS using the
long
library for big integers. If CosmJS decides to change that to another lib (e.g. the native TypeScriptbigint
) which is a breaking change, they would need to wait for the proto pkg version to bump... which by design would take a long time.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I agree with the idea of module specific packes that are close to Cosmos SDK versioning, enforcing the same version number across different client ecosystems seems to be very restricting. There can be breaking changes in the code generation that are not related to the API itself as Amury described. Some ecosystems structure in smaller packages, some in larger. Also note that the code generation does not necessarily happen in a type library. You can always add types in the application. Then you suddenly bind Cosmos SDK version to the version of the app.