Skip to content
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

Mark v0 protos with deprecations #28

Merged
merged 1 commit into from
Feb 10, 2022
Merged

Conversation

samkim
Copy link
Member

@samkim samkim commented Feb 7, 2022

Adds deprecations to v0 proto files using the findings below to provide the most granular notice in generated code.

Result of deprecated = true in generated code

Client rpc message file
go deprecation comment deprecation comment deprecation comment
python none none none
node @deprecated @deprecated @deprecated on file
java none @java.lang.Deprecated @java.lang.Deprecated on classes
ruby none none none

@samkim samkim marked this pull request as ready for review February 8, 2022 18:49
@@ -24,6 +27,7 @@ message RelationTuple {
}

message ObjectAndRelation {
option deprecated = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Several of the core types (ObjectAndRelation, RelationRerefence, and RelationTupleTreeNode at least) are used in the dispatch api. Marking them deprecated here will (I think?) make our linters complain about using deprecated types

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh interesting, I didn't expect the generated deprecated comment in go code to be parsed by the linter. We can remove them for these messages in the interim.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep! Most recently it was some of the grpc options we were using that were deprecated. I looked it up and it's staticcheck that complains: https://staticcheck.io/docs/checks/#SA1019

Other options would be to take these types and copy them into the dispatch API and only mark these v0 versions deprecated, or we can mark these deprecated now and just tell the linter to ignore it with a comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we going to block on that? It seems to me like eventually the dispatch API should use its own types or be migrated to the latest.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm leaning toward leaving the messages in core un-deprecated. The services are all still annotated and we can avoid having to add ignore comments a bunch of places. We can separately work on copying these into the dispatch API.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI did the same for namespace message definitions because they're used in schemadsl

@jzelinskie jzelinskie linked an issue Feb 9, 2022 that may be closed by this pull request
@samkim samkim force-pushed the deprecate-v0 branch 2 times, most recently from 7d93cb8 to 0bdb2e0 Compare February 9, 2022 22:35
@samkim
Copy link
Member Author

samkim commented Feb 10, 2022

@jzelinskie any other feedback?

@jzelinskie jzelinskie merged commit 8ae4cf5 into authzed:main Feb 10, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Feb 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mark authzed.api.v0 as deprecated
3 participants