Open ShellyKa13 opened 3 weeks ago
It seems that the next step would be to turn this FG on by default for at least one release. @EdDev wdyt? Do we have a formal policy in place for aging feature gates?
We have this: https://github.com/kubevirt/community/blob/main/design-proposals/feature-lifecycle.md#release-stage-transition-table
Unlike Kubernetes, we have not recommended to enable a FG by default in Beta. Reasoning that even if in Beta, there is still a risk of the feature to be dropped, causing backward compatibility issues with the users. By having the FG enabled by default, we leave no decision on the user side, taking on the admin behalf the risk, which seems wrong.
If there is a D/S project/deployment that uses this feature already, enabling it and exercising it in the field, I think it can give you the confident to go ahead and GA it without the need to do anything special.
Said that, you could have an exception and decide otherwise. Just make sure you give a good reason so it will not become the standard unintentionally.
Claim adoption should be the general behavior without a need for a feature gate. We should remove it over the course of several kubevirt releases.