-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
api: force migrate v3alpha -> v3 #18392
Conversation
Also adjust wip status for some things that are known to be used in production. Fixes #17920 Signed-off-by: Matt Klein <mklein@lyft.com>
cc @envoyproxy/api-shepherds |
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 risk should be "high", in the sense this is likely to break a lot of people who are not following the letter of the law on API stability policy. Caveat emptor, I know, but if I was scanning commit logs for changes to pay attention to, this is one.
@@ -1,10 +1,10 @@ | |||
syntax = "proto3"; | |||
|
|||
package envoy.extensions.cache.simple_http_cache.v3alpha; | |||
package envoy.extensions.cache.simple_http_cache.v3; |
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 it's totally valid to break stuff since these are alpha APIs. One alternative we have though is to clone v3alpha to v3 and just not support v3alpha in Envoy. I'm not sure how useful that would be, but if other API clients depend on alpha protos, that could be less bad. @markdroth any opinions here?
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 don't have any strong opinion on this. gRPC doesn't use any alpha APIs, and I don't think that GCP depends on any of these APIs either.
In principle, I guess I agree that not forcibly breaking anyone who is depending on the alpha protos might be a bit more user-friendly, but at the same time, the whole point of alpha is to be able to make breaking changes, so... I can see both sides of this.
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.
Unless there are strong objections I'm just going to suggest we pull the bandaid here and get it done. If we receive extreme complaining we could potentially add the files back but let's see what happens?
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.
That sounds fine to me.
Updated |
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.
LGTM contingent on other API shepherds (in particular @markdroth) sign-off.
@@ -1,10 +1,10 @@ | |||
syntax = "proto3"; | |||
|
|||
package envoy.extensions.cache.simple_http_cache.v3alpha; | |||
package envoy.extensions.cache.simple_http_cache.v3; |
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 don't have any strong opinion on this. gRPC doesn't use any alpha APIs, and I don't think that GCP depends on any of these APIs either.
In principle, I guess I agree that not forcibly breaking anyone who is depending on the alpha protos might be a bit more user-friendly, but at the same time, the whole point of alpha is to be able to make breaking changes, so... I can see both sides of this.
Signed-off-by: Matt Klein <mklein@lyft.com>
/lgtm api |
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.
(given the dual shephard sign-off I'm fine with the actual changes)
Also adjust wip status for some things that are known to be used in
production.
Fixes #17920
Risk Level: High (for code, low, but there will be unhappy v3alpha users surely.)
Testing: Existing tests
Docs Changes: N/A
Release Notes: Added
Platform Specific Features: N/A