Disallow or limit changing default values in API protos across releases

[htuch]

A sometimes used pattern when fixing bugs has been to add a BoolValue and default false for the fix in the current release and default true in the next. This is really a breaking wire change, since while it doesn't affect wire encoding, the semantics change in a way that makes it hard to consistently reuse protos across versions.

It can be done safely in some situations, e.g. if a BoolValue is introduced and its semantics are opt-in and then we default true later, but we need to spell this out in the Breaking Change Policy and API style guide.

This is related to #6271.

[htuch]

The more that I think about this, I think my assertion above that this is safe if you go false --> true is not correct, at least in the absence of further version negotiation between client/server or hard rule about management servers always setting fields explicitly rather than relying on defaults.

[alyssawilk]

Internal best practice which works for monolithic rollouts is to flag-protect "if not set, change the default value" so folks can runtime-override the new default setting, flip the flag, then change the default. Which is a lot nicer than the add-an-equivalent-field and move over to it dance.

Unfortunately beyond the process being painful, I'm less convinced that'd help non-Envoy users of xDS and I don't have any great ideas of how to consistently provide a similar workaround :-/

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.