Re: Require features to transition out of beta

[Jordan Liggitt]

+ kubernetes-api-reviewers, kubernetes-sig-leads

On Wed, Oct 2, 2019 at 10:00 AM Jordan Liggitt <lig...@google.com> wrote:

I agree that a lifecycle plan like this is needed. We don't want neglect to be mistaken for stability.

This approach does several things I like:

• Lets us declare the lifetime of a new beta API when it is introduced. It's very clear to say something like "The v1beta1 version of this API will be evaluated during v1.16 and v1.17, then deprecated in v1.18 (in favor of a new beta version, a GA version, or with no replacement), then no longer served in v1.21")
• Is long enough to allow a given use of a beta API to work with all currently supported Kubernetes versions
• Makes it clearer to consumers that beta APIs are not intended to be long-term foundations (O(years))
• Makes it clearer to developers/maintainers that promotion to beta does not mean the commitment to work on and progress the feature is complete

We'll continue to work through existing beta APIs and the plans/timelines to progress/graduate/deprecate those, but I like this as a starting point for new efforts.

On Wed, Oct 2, 2019 at 9:17 AM David Eads <de...@redhat.com> wrote:

When a feature reaches beta, it is turned on by default.  This is great for getting feedback, but it can also lead to state where users and vendors start building important infrastructure against APIs that are not considered stable. In addition, once a feature is on by default, the incentive to further stabilize it appears to diminish. For evidence, see the features that have been beta for a long time: CSRs and Ingresses are good examples. If we're honest with ourselves, a single actor has been cleaning up behind a lot of the project to unstick perma-beta APIs.

APIs and features should not languish in beta, to prevent this I've opened kep/1266.  It proposes that features should take feedback and progress towards GA by either

1. meeting GA criteria and getting promoted, or
   
2. having a new beta and deprecating the previous beta
   

This must happen within six months (two releases).  If it does not, the API will be deprecated with an announced intent to remove the feature per the deprecation policy (two more releases).  This means that the original beta will be accepted for four releases total.

This approach allows making responsible progress without rushing to GA.  The new beta levels will prevent serialized manifests from becoming the defacto standard and will help keep API and feature users aware of the status.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/64fef762-2b9f-4489-86da-cf705157efee%40googlegroups.com.