config: officially deprecating deprecated_v1 fields#4780
config: officially deprecating deprecated_v1 fields#4780alyssawilk wants to merge 2 commits intoenvoyproxy:masterfrom
Conversation
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
@envoyproxy/senior-maintainers still good with this? If so I'll land and envoy-announce. |
|
|
||
| ## Version 1.9.0 (pending) | ||
|
|
||
| * Use of the v2 API "deprecated_v1" fields is deprecated. |
…ve deprecated_v1 in this release. alternately I could remove it?) Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
| ## Version 1.8.0 (Oct 4, 2018) | ||
|
|
||
| * Use of the v1 API (including `*.deprecated_v1` fields in the v2 API) is deprecated. | ||
| * Use of the v1 API is deprecated. |
|
does this include tcp_proxy? coz we couldn't remove the tcp proxy deprecated_v1 config (@venilnoronha had a Pr). I think it boiled down to lack of source IP match in filter chain match. |
|
PR #4625 is still open. |
|
|
||
| // [#not-implemented-hide:] | ||
| DeprecatedV1 deprecated_v1 = 7; | ||
| DeprecatedV1 deprecated_v1 = 7 [deprecated = true]; |
There was a problem hiding this comment.
I think there are more than this as @rshriram points out? I'm pretty sure we have a bunch of these...
There was a problem hiding this comment.
I believe the rest were already deprecated :-)
I'm going to close this out regardless though - I'd thought updating the deprecation notice from last release to this release would make deprecation schedule more clear but if we'd prefer to not rewrite history I don't think deprecating it every version until we remove is helpful
5 participants
For removal in the next release ~3 months out
Risk Level: Low (deprecating one lingering proto field)
Testing: n/a
Docs Changes: updated DEPRECATED.md
Release Notes: n/a
Deprecated: deprecated deprecated config