-
Notifications
You must be signed in to change notification settings - Fork 345
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
How to Organize API Types #809
Comments
From the 5/13/22 EG community call, @youngnick proposes:
|
My recommendation slightly differs from the above. I suggest having separate config and extension API groups. Helper functions, validation, etc. will live within each group for the associated types. This allows versioning the extension types separately from the config types. For example, the EnvoyProxy type can graduate faster than extension API types since they may be more widely used. Additionally, it simplifies transitioning the extension APIs into a separate repo. Thoughts @youngnick |
+1 to |
@danehans, I think that's fine, although I suggest standardizing the import names to make reading the code easier. |
@arkodg @AliceProxy @Xunzhuo @skriss please comment if you have issue with the approach in #809 (comment). |
@arkodg thanks for catching this. I updated the description.
If our long-term intention is for extensions to live outside of the EG repo, they'll be revisioned separately. |
this was discussed in the community meeting today This will be a breaking change for users using the @envoyproxy/gateway-maintainers, would be great if you can 👍 👎 ? |
Until we're at 1.0.0, we should not be afraid of breaking changes. Go for it. |
+1 for callpsing everything into |
@envoyproxy/gateway-steering-committee @envoyproxy/nighthawk-maintainers we need a certain policy for support and deprecation. |
* this keeps all CRDs/APIs under the gateway.envoyproxy.io group * this is a breaking change, that needs to be highlighted in the release notes. Undesirable but acceptable since these APIs are experimental (alpha) and are not yet stable Fixes: envoyproxy#809 Signed-off-by: Arko Dasgupta <arko@tetrate.io>
* this keeps all CRDs/APIs under the gateway.envoyproxy.io group * this is a breaking change, that needs to be highlighted in the release notes. Undesirable but acceptable since these APIs are experimental (alpha) and are not yet stable Fixes: envoyproxy#809 Signed-off-by: Arko Dasgupta <arko@tetrate.io>
* this keeps all CRDs/APIs under the gateway.envoyproxy.io group * this is a breaking change, that needs to be highlighted in the release notes. Undesirable but acceptable since these APIs are experimental (alpha) and are not yet stable Fixes: envoyproxy#809 Signed-off-by: Arko Dasgupta <arko@tetrate.io>
* move EnvoyProxy API to gateway.envoyproxy.io * this keeps all CRDs/APIs under the gateway.envoyproxy.io group * this is a breaking change, that needs to be highlighted in the release notes. Undesirable but acceptable since these APIs are experimental (alpha) and are not yet stable Fixes: #809 Signed-off-by: Arko Dasgupta <arko@tetrate.io> * fix config Signed-off-by: Arko Dasgupta <arko@tetrate.io> * fix rbac Signed-off-by: Arko Dasgupta <arko@tetrate.io> --------- Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Currently, EG API types reside in 2 locations:
api/config/v1alpha1
.api/v1alpha1
.This makes imports a bit confusing:
It's unclear what API types are being imported from
github.com/envoyproxy/gateway/api/v1alpha1
.The text was updated successfully, but these errors were encountered: