Ok, then lets increase the graduation period to 2 releases. If we see that this is super easy for us to do, then we can shorten it in the future.
Cheers, Till On Mon, Dec 6, 2021 at 9:54 AM Chesnay Schepler <ches...@apache.org> wrote: > Given that you can delay the graduation if there is a good reason for > it, we should be able to cover that case even if the graduation would > happen by default after 1 month. > > That said, personally I would also be in favor of 2 releases; we see > plenty of users not upgrading to every single Flink version, and this > may give us a bit more coverage. > > On 06/12/2021 09:20, Ingo Bürk wrote: > > 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 > >>>> > >
