Hi Till, This makes sense to me, in general. I am wondering two things:
* is one release to promote enough or will it lead to a lot of exclusions? FLIP-27, for example, took much longer to stabilize, I believe. If we think, this is quite a strict rule, then in my experience, let's rather start with an easier rule that is broken less, then a strict rule that is broken from the start. * If I could choose whether we focus on this FLIP or another follow up of FLIP-196 like establishing stability guarantees for the REST API, I would choose the latter. Cheers, Konstantin On Thu, Dec 2, 2021 at 3:58 PM Till Rohrmann <trohrm...@apache.org> wrote: > Hi everyone, > > As promised, here is the follow-up FLIP [1] for discussing how we can > ensure that newly introduced APIs are being stabilized over time. This FLIP > is related to FLIP-196 [2]. > > The idea of FLIP-197 is to introduce an API graduation process that forces > us to increase the API stability guarantee unless there is a very good > reason not to do so. So the proposal is to reverse the process from opt-in > (increasing the stability guarantee explicitly) to opt-out (deciding that > an API cannot be graduated with a good reason). > > Since every process breaks if it is not automated, we propose a richer set > of API stability annotations that can capture enough information so that we > can implement a test that fails if we fail to follow the process. > > Looking forward to your feedback. > > Hopefully, we can provide our users a better experience when working with > Flink because we offer more stable APIs and make them available faster. > > [1] https://cwiki.apache.org/confluence/x/J5eqCw > [2] https://cwiki.apache.org/confluence/x/IJeqCw > > Cheers, > Till > -- Konstantin Knauf https://twitter.com/snntrable https://github.com/knaufk
