Hi Till, Overall I whole-heartedly agree with the proposals in this FLIP. Thank you for starting this discussion as well! This seems like something that could be tested quite nicely with ArchUnit as well; I'll be happy to help should the FLIP be accepted.
> I would propose per default a single release. The step from PublicEvolving to Public feels more important to me, and I would personally suggest making this transition a bit longer. We have a bit of a chicken-egg problem here, because the goal of your FLIP is, ultimately, also to motivate faster adoption of new Flink versions, but the status quo prevents that; if we mature APIs too quickly, we risk losing out on important feedback. Therefore, I would propose starting slower here, and rather think about shortening that cycle in the future. Best Ingo On Thu, Dec 2, 2021 at 3:57 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 >
