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 >
