Hi Julian, Could you please remove the duplicated "RE:" in the topic of the reply? That way we can continue this discussion to the original thread. (Apache deals with it correctly, but not all email clients/services do, e.g. GMail)
Thanks, Alex On Tue, 5 Dec 2023 at 09:39, Payne, Julian <julp...@amazon.co.uk.invalid> wrote: > Hey all, > Thanks for this proposal, I think it makes a lot of sense. I am, curious > to know what time horizon we would consider for LTS of 1.x. Customers value > knowing when versions will deprecate so they can build migration into their > planning and resourcing cycles, so I would be in favour of being > transparent on how long the community will support 1.x. > > Thanks > > > Julian > > On 2023/07/26 14:16:43 Konstantin Knauf wrote: > > Hi Jing, > > > > > How could we help users and avoid this happening? > > > > I don't think we will be able to avoid this in all cases. And I think > > that's ok. Its always a trade-off between supporting new use cases and > > moving the project forward and backwards compatibility (in a broad > sense). > > For example, we dropped Mesos support in a minor release in the past. If > > you're only option for running Flink was Mesos, you were stuck on Flink > > 1.13 or so. > > > > So, I think, it is in the end a case-by-case decision. How big is the > cost > > of continued support a "legacy feature/system" and how many users are > > affected to which degree by dropping it? > > > > Best, > > > > Konstantin > > > > > > Am Di., 25. Juli 2023 um 18:34 Uhr schrieb Jing Ge > > <ji...@ververica.com.invalid>: > > > > > Hi Konstantin, > > > > > > I might have not made myself clear enough, apologies. The > > > source-/sink-function was used as a concrete example to discuss the > pattern > > > before we decided to offer LTS. The intention was not to hijack this > thread > > > to discuss how to deprecate them. > > > > > > We all wish that the only thing users need to migrate from Flink 1.x > to 2.0 > > > is some code changes in their repos and we all wish users will > migrate, if > > > LTS has long enough support time. But the question I tried to discuss > is > > > not the wish but the "How?". We might be able to toss the high > migration > > > effort aside(we shouldn't), since it is theoretically still doable if > users > > > have long enough time, even if the effort is extremely high. Another > > > concern is that if "function regressions" is allowed in 2.0, i.e. if > 2.0 > > > has a lack of functionalities or bugs compared to 1.x, there will be > no way > > > for users to do the migration regardless of whether we encourage them > to > > > migrate or they haven been given enough time(how long is enough?) > because > > > LTS has been offered. How could we help users and avoid this happening? > > > > > > Best regards, > > > Jing > > > > > > On Tue, Jul 25, 2023 at 6:57 PM Konstantin Knauf <kn...@apache.org> > > > wrote: > > > > > > > Hi Jing, > > > > > > > > let's not overindex on the Source-/SinkFunction discussion in this > > > thread. > > > > > > > > We will generally drop/break a lot of APIs in Flink 2.0. So, > naturally > > > > users will need to make more changes to their code in order to > migrate > > > from > > > > 1.x to Flink 2.0. In order to give them more time to do this, we > support > > > > the last Flink 1.x release for a longer time with bug fix releases. > > > > > > > > Of course, we still encourage users to migrate to Flink 2.0, because > at > > > > some point, we will stop support Flink 1.x. For example, if we > followed > > > > Marton's proposal we would support Flink 1.x LTS for about 2 years > > > (roughly > > > > 4 minor release cycles) instead of about 1 year (2 minor release > cycles) > > > > for regular minor releases. This seems like a reasonable timeframe > to me. > > > > It also gives us more time to discover and address blockers in > migrating > > > to > > > > Flink 2.x that we are not aware of right now. > > > > > > > > Best, > > > > > > > > Konstantin > > > > > > > > Am Di., 25. Juli 2023 um 12:48 Uhr schrieb Jing Ge > > > > <ji...@ververica.com.invalid>: > > > > > > > > > Hi all, > > > > > > > > > > Overall, it is a good idea to provide the LTS release, but I'd > like to > > > > > reference a concrete case as an example to understand what > restrictions > > > > the > > > > > LTS should have. > > > > > > > > > > Hypothetically, Source-/Sink- Function have been deprecated in 1.x > LTS > > > > and > > > > > removed in 2.0 and the issues[1] are not solved in 2.0. This is a > > > typical > > > > > scenario that the old APIs are widely used in 1.x LTS and the new > APIs > > > in > > > > > 2.0 are not ready yet to take over all users. We will have the > > > following > > > > > questions: > > > > > > > > > > 1. Is this scenario allowed at all? Do we all agree that there > could be > > > > > some features/functionalities that only work in 1.x LTS after 2.0 > has > > > > been > > > > > released? > > > > > 2. How long are we going to support 1.x LTS? 1 year? 2 years? As > long > > > as > > > > > the issues that block users from migrating to 2.0 are not solved, > we > > > > can't > > > > > stop the LTS support, even if the predefined support time expires. > > > > > 3. What is the intention to release a new version with (or without) > > > LTS? > > > > Do > > > > > we still want to engage users to migrate to the new release asap? > If > > > the > > > > > old APIs 1.x LTS offer more than the new APIs in 2.0 or it is > almost > > > > > impossible to migrate, double effort will be required to maintain > those > > > > > major releases for a very long time. We will be facing many > cohorts. > > > > > > > > > > IMHO, we should be clear with those questions before we start > talking > > > > about > > > > > LTS. WDYT? > > > > > > > > > > Best regards, > > > > > Jing > > > > > > > > > > > > > > > [1] > https://lists.apache.org/thread/734zhkvs59w2o4d1rsnozr1bfqlr6rgm > > > > > > > > > > On Tue, Jul 25, 2023 at 6:08 PM Márton Balassi < > > > balassi.mar...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > Hi team, > > > > > > > > > > > > +1 for supporting the last 1.x for a longer than usual period of > time > > > > and > > > > > > limiting it to bugfixes. I would suggest supporting it for > double the > > > > > usual > > > > > > amount of time (4 minor releases). > > > > > > > > > > > > On Tue, Jul 25, 2023 at 9:25 AM Konstantin Knauf < > kn...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > yes, I think, it makes sense to support the last 1.x release > longer > > > > > than > > > > > > > usual. This should be limited to bugfixes in my opinion. > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Konstantin > > > > > > > > > > > > > > Am Di., 25. Juli 2023 um 07:07 Uhr schrieb Xintong Song < > > > > > > > tonysong...@gmail.com>: > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > Providing a longer supporting period for the last 1.x minor > > > release > > > > > > makes > > > > > > > > sense to me. > > > > > > > > > > > > > > > > I think we need to be more specific about what LTS means > here. > > > > > > > > > > > > > > > > - IIUC, that means for the last 1.x minor release, we will > > > keep > > > > > > > > providing 1.x.y / 1.x.z bugfix release. This is a stronger > > > > support > > > > > > > > compared > > > > > > > > to regular minor releases which by default are only > supported > > > > for > > > > > 2 > > > > > > > > minor > > > > > > > > release cycles. > > > > > > > > - Do we only provide bug fixes for the LTS release, or do > we > > > > also > > > > > > > allow > > > > > > > > backporting features to that release? > > > > > > > > - How long exactly shall we support the LTS release? > > > > > > > > > > > > > > > > And maybe we can make this a general convention for last > minor > > > > > releases > > > > > > > for > > > > > > > > all major releases, rather than only discuss it for the 2.0 > > > version > > > > > > bump. > > > > > > > > > > > > > > > > @Leonard, > > > > > > > > > > > > > > > > I'd like to clarify that there are no community decisions > yet on > > > > > > release > > > > > > > > 2.0 after 1.19. It is possible to have 1.20 before 2.0. > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > Xintong > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 25, 2023 at 11:54 AM Leonard Xu <xb...@gmail.com > > > > > > > wrote: > > > > > > > > > > > > > > > > > +1, it’s pretty necessary especially we deprecated so many > APIs > > > > in > > > > > > 1.18 > > > > > > > > > and plan to remove in 2.0. > > > > > > > > > > > > > > > > > > The 1.19 should be a proper version for LTS Release. > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > Leonard > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Jul 25, 2023, at 3:30 AM, Alexander Fedulov < > > > > > > > > > alexander.fedu...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > > > > > > > > > Recently, there were a lot of discussions about the > > > deprecation > > > > > of > > > > > > > > > various > > > > > > > > > > APIs for the upcoming 2.0 release. It appears there are > two > > > > main > > > > > > > > > motivations > > > > > > > > > > with opposing directions, causing these discussions to > remain > > > > > > > > unsettled. > > > > > > > > > On > > > > > > > > > > one hand, there's a desire to finally trim a wide range > of > > > > legacy > > > > > > > APIs, > > > > > > > > > some > > > > > > > > > > lingering around since the beginning of the 1.x release > line > > > > (as > > > > > > far > > > > > > > > > back as > > > > > > > > > > 2016). On the other hand, there is a commitment to > uphold our > > > > > > > > guarantees > > > > > > > > > to > > > > > > > > > > the users, ensuring a smooth transition. > > > > > > > > > > > > > > > > > > > > I believe we could reconcile these two motivations. My > > > > > proposition > > > > > > is > > > > > > > > to > > > > > > > > > > designate the final release of the 1.x timeline as a > > > Long-Term > > > > > > > Support > > > > > > > > > (LTS) > > > > > > > > > > release. By doing so, we would: > > > > > > > > > > > > > > > > > > > > 1. Enable more efficient cleanup and be liberated to > > > introduce > > > > > more > > > > > > > > > breaking > > > > > > > > > > changes, paving the way for greater innovation in the > 2.0 > > > > > > release. > > > > > > > > > > 2. Sustain a positive user experience by granting enough > time > > > > for > > > > > > the > > > > > > > > > > changes > > > > > > > > > > introduced in 2.0 to stabilize, allowing users to > > > confidently > > > > > > > > > transition > > > > > > > > > > their production code to the new release. > > > > > > > > > > > > > > > > > > > > I look forward to hearing your thoughts on this proposal. > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > https://twitter.com/snntrable > > > > > > > https://github.com/knaufk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > https://twitter.com/snntrable > > > > https://github.com/knaufk > > > > > > > > > > > > > -- > > https://twitter.com/snntrable > > https://github.com/knaufk > > >
