Hi Till, from my (admittedly limited) experience with how far projects lag behind in terms of Flink versions – yes, the combined time it would take to mature then seems reasonable enough for a sufficient adoption, IMO.
Another reason why I think two releases as a default for the last step makes sense: say you mature an API to PublicEvolving. Typically, there will be issues found afterwards. Even if you address these in the very next release cycle, a duration of one release would mean you fully mature the API in the same release in which things are still being fixed; intuitively, it makes sense to me that the step to Public would come after a period of no changes needed, however. Ingo On Fri, Dec 3, 2021 at 4:55 PM Till Rohrmann <trohrm...@apache.org> wrote: > Hi Ingo, thanks for your feedback. > > Do you think that two release cycles per graduation step would be long > enough or should it be longer? > > Cheers, > Till > > On Fri, Dec 3, 2021 at 4:29 PM Ingo Bürk <i...@ververica.com> wrote: > > > 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 > > > > > >
