Removal date suppose to be the date when feature gate will be removed, but that is irrelevant since once it is marked as Stable cannot be changed anyway. See https://github.com/open-telemetry/opentelemetry-collector/blob/main/featuregate/registry.go#L150

[bogdandrutu]

No description provided.

[MovieStoreGuy]

Just quickly looking at what you're referring to, do you mean https://github.com/open-telemetry/opentelemetry-collector/blob/main/featuregate/registry.go#L110 by chance?

[TylerHelmuth]

I think there are 2 ways to tackle this:

1. Stick with the k8s process and have ToVersion represent the version that the gate is completely removed. With this method users do not have an idea when the gate will be marked stable, but do know when the gate was removed.
2. Start requiring ToVersion when promoting a feature gate to beta and have it represent when a feature will be marked stable. Allow it to be set with alpha optionally to represent when a get will be marked deprecated. With this method users will know when a gate will be marked stable or deprecated, but it locks in beta to a set timeframe when maybe we want more flexibility on how long something stays in beta.

[TylerHelmuth]

Based on the discussion in the SIG meeting today we will go with option 1 with the following additions:

• A stable gate should be able to be set to true without failing.
• A deprecated gate should be able to be set to false without failing.
• When a stable or deprecated gate is set a warning log should be written explaining that the gate will be removed in ToVersion and that continued use of the gate will cause errors after that version.