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 <j...@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 <kna...@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 > > <j...@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 <kna...@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 <xbjt...@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
