Hi everyone, Thanks a lot for all your input. I hope that I could answer most of the questions. I would now start a vote on this FLIP.
Cheers, Till On Tue, Dec 7, 2021 at 3:05 PM Till Rohrmann <trohrm...@apache.org> wrote: > Hi Timo, > > 1) I haven't fully thought where to put it but I guess that flink-core > might be a good place for the FlinkVersion. We should then also unify any > other enums if possible. > > 2) I think it makes sense to also review our deprecation process. I think > it makes a lot of sense to add since when something is deprecated and > establish a process for removing it (e.g. after one release and if not then > state why). For the sake of brevity of this FLIP, I would move this > discussion to a follow-up FLIP, though. > > Cheers, > Till > > On Mon, Dec 6, 2021 at 11:35 AM Timo Walther <twal...@apache.org> wrote: > >> Hi Till, >> >> thanks for starting this discussion. I think this topic should have been >> discussed way earlier. I have two questions: >> >> 1) It might be an implementation detail but where do you expect this >> `FlinkVersion` to be located? This is actually a quite important class >> that also needs to be made available for other use cases. For the SQL >> upgrade story we will definitely need a similar enum. And I think we >> have something similar for other tests (see `MigrationVersion`). For >> reducing releasing overhead, it would be good to unify all these >> "version metadata". >> >> 2) Deprecations: Shall we also start versioning deprecation decisions? >> Esp. for Experimental/PublicEvolving interfaces we should remove >> deprecated code in time. We should also let users know when we are >> planning to remove code. E.g. clearly indicate that the deprecation will >> happen in the next major version? >> >> Regards, >> Timo >> >> On 06.12.21 10:04, Till Rohrmann wrote: >> > 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 >> >>>>>> >> >> >> >> >> > >> >>
