Thanks for the feedback Konstantin. * I agree that if we think that one release cycle to graduate is too short, then we should extend it to something we believe we can achieve. For FLIP-27, I think we could have stabilized the API faster if it had been our priority (not sure whether two release cycles would have been enough though). * REST API stabilization is unrelated to this FLIP. Hence, I would like to exclude it from this discussion.
Cheers, Till On Fri, Dec 3, 2021 at 9:42 AM Konstantin Knauf <kna...@apache.org> wrote: > 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 >
