Replies: 3 comments
-
@robscott feel free to provide additional context if needed. |
Beta Was this translation helpful? Give feedback.
-
Thanks for starting this conversation @danehans! In my opinion, the strongest arguments in favor of something like this would be to warn users when:
It's likely that 2 can be solved with the The strongest arguments against something like this would be:
A caveat to 1 is that Gateway API only offers backwards compatibility guarantees on standard channel, not experimental channel. It could be incredibly useful to understand if an implementation supports v1.1 (BackendTLSPolicy v1alpha3) or v1.0 (BackendTLSPolicy v1alpha2). You could argue that the important detail there is API Version, not bundle/semantic version though. |
Beta Was this translation helpful? Give feedback.
-
As mentioned in the meeting today, it should count for something that we've documented this in the 1.0 CHANGELOG, declared it an Issue in #2077, and implemented it in (#2384). More importantly, there are at least two implementations of |
Beta Was this translation helpful? Give feedback.
-
PR #3368 adds a conformance test for the GatewayClass SupportedVersion feature. The PR sparked discussion regarding the feature's relevancy, whether CRDs should be watched by controllers, etc. This discussion should be used to continue the conversation instead.
Beta Was this translation helpful? Give feedback.
All reactions