I think making the last minor release before a major release an LTS release with extended support makes sense. I cannot think of a reason against the four minor release cycles suggested by Marton. Only providing bug fixes and not allowing features to be backported sounds reasonable to keep the maintenance costs low.
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. I guess we should also make it explicit that we only support one LTS version to reduce the number of supported versions to 3 (x.y, x.[y-1], [x-1].z). I have the impression that this is implied by everyone. I wanted to mention this as an additional item, anyway. ...even though it would only become a topic when discussing 3.0. Matthias On Tue, Jul 25, 2023 at 6:33 PM Jing Ge <j...@ververica.com.invalid> wrote: > 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 > > >
