You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the value of the beta feature gates if they are off by default? Do we make a different promise in regards to not breaking things in beta, such as an X number of releases before a beta feature gets removed or a breaking change is implemented?
can we define any generic graduation criteria, i.e after X number of releases a feature could be promoted? Is it reasonable to require user feedback to graduate a feature alpha -> beta and how do we get that/what setups are sufficient?
Most features of the alpha features will probably require looking at individually to define what needs to be done to graduate them/whether there are any reported issues etc.
At the moment all our features are in alpha.
We have also marked beta features as off by default:
This is not defined in cert-manager codebase- it seems to come from component-base as we use that library to define our feature gates.
Meanwhile upstream Kubernetes have beta feature gates on by default
Should we follow upstream and have beta features on by default?
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/feature-gates.md
https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-stages
The text was updated successfully, but these errors were encountered: