Hi Ufuk, thanks for your feedback, it seems we are in sync about all major points.
@everyone: I expanded the FLIP with a short LTS policy description that we will later add to the docs: *Long-Term Support (LTS) Policy:* Since major versions typically introduce breaking changes, the final minor release of each major version line is designated as a Long-Term Support (LTS) version. Supported for a fixed period of two years with only bug fixes and security updates, these LTS versions provide a stable and predictable timeframe for preparing and transitioning to the next major Apache Flink release. Please let me know if you think it misses something. I will start a voting thread shortly. Best, Alex On Wed, 12 Jun 2024 at 22:51, Ufuk Celebi <u...@apache.org> wrote: > Hi folks! > > 1) Big +1 on being strict with limiting the LTS version to patches and no > feature backports. I think that it would open up a big can of worms. What > does it even mean to backport a feature to a LTS version? My understanding > is that we want to designate a single 1.x version as LTS. But if we > backport a feature, we would technically need to bump the minor version and > then we are basically back at maintaining features for 1.x. Let me know if > I’m misunderstanding something. > > 2) It also seems fine to me to stick to 1.x and 2.x concretely in the FLIP > since it’ll be our first LTS version and we don’t anticipate (as of today) > many overlapping LTS versions. It actually makes it clearer to me what > we’re talking about. > > 3) 2 years seems like a good starting point to me. If anything, I’m > wondering whether it should be longer given that there are many users on > old versions even today. It’s probably best to stick to this number and > expand if needed down the line (as opposed to starting with a longer > duration and then running into problems). > > Cheers, > > Ufuk > > > On 11. Jun 2024, at 15:44, Alexander Fedulov < > alexander.fedu...@gmail.com> wrote: > > > > Hi Matthias, > > > > I think we can include this generic semantic into the writeup of the LTS > > definition for the Flink website (last item in the Migration Plan). > > Talking about 1.x and 2.x feels more natural than about N.x and N+1.x - > I'd > > prefer not to overcomplicate things here. > > Should the gap before the next major release match this one (eight > years), > > it would be appropriate to reconsider the project stance and vote anew if > > required. > > > > Best, > > Alex > > > > On Mon, 27 May 2024 at 09:02, Matthias Pohl <map...@apache.org> wrote: > > > >> Hi Alex, > >> thanks for creating the FLIP. One question: Is it intentionally done > that > >> the FLIP only covers the 1.x LTS version? Why don't we make the FLIP > >> generic to also apply to other major version upgrades? > >> > >> Best, > >> Matthias > >> > >> On Sat, May 25, 2024 at 4:55 PM Xintong Song <tonysong...@gmail.com> > >> wrote: > >> > >>>> > >>>> I think our starting point should be "We don't backport features, > >> unless > >>>> discussed and agreed on the Dev mailing list". > >>> > >>> > >>> This makes perfect sense. In general, I think we want to encourage > users > >> to > >>> upgrade in order to use the new features. Alternatively, users can also > >>> choose to maintain their own custom patches based on the LTS version. I > >>> personally don't see why backporting new features to old releases is > >>> necessary. In case of exceptions, a mailing list discussion is always a > >>> good direction to go. > >>> > >>> > >>> Best, > >>> > >>> Xintong > >>> > >>> > >>> > >>> On Fri, May 24, 2024 at 9:35 PM David Radley <david_rad...@uk.ibm.com> > >>> wrote: > >>> > >>>> Hi Martjin and Alex, > >>>> I agree with your summaries, it will be interesting to see what > >> requests > >>>> there might be for back ports. > >>>> Kind regards, David. > >>>> > >>>> > >>>> > >>>> > >>>> From: Alexander Fedulov <alexander.fedu...@gmail.com> > >>>> Date: Friday, 24 May 2024 at 14:07 > >>>> To: dev@flink.apache.org <dev@flink.apache.org> > >>>> Subject: [EXTERNAL] Re: [DISCUSS] Proposing an LTS Release for the 1.x > >>> Line > >>>> @David > >>>>> I agree with Martijn that we only put features into version 2. Back > >>>> porting to v1 should not be business as usual for features, only for > >>>> security and stability changes. > >>>> Yep, this choice is explicitly reflected in the FLIP [1] > >>>> > >>>> @Martijn > >>>>> I think our starting point should be "We don't backport features, > >>> unless > >>>> discussed and agreed on the Dev mailing list". > >>>> I agree - the baseline is that we do not do that. Only if a very > >>> compelling > >>>> argument is made and the community reaches consensus, exceptions could > >>>> potentially be made, but we should try to avoid them. > >>>> > >>>> [1] https://cwiki.apache.org/confluence/x/BApeEg > >>>> > >>>> Best, > >>>> Alex > >>>> > >>>> On Fri, 24 May 2024 at 14:38, Martijn Visser < > martijnvis...@apache.org > >>> > >>>> wrote: > >>>> > >>>>> Hi David, > >>>>> > >>>>>> If there is a maintainer willing to merge backported features to > >> v1, > >>> as > >>>>> it is important to some part of the community, this should be > >> allowed, > >>> as > >>>>> different parts of the community have different priorities and > >>> timelines, > >>>>> > >>>>> I don't think this is a good idea. Backporting a feature can cause > >>> issues > >>>>> in other components that might be outside the span of expertise of > >> the > >>>>> maintainer that backported said feature, causing the overall > >> stability > >>> to > >>>>> be degraded. I think our starting point should be "We don't backport > >>>>> features, unless discussed and agreed on the Dev mailing list". That > >>>> still > >>>>> opens up the ability to backport features but makes it clear where > >> the > >>>> bar > >>>>> lies. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Martijn > >>>>> > >>>>> On Fri, May 24, 2024 at 11:21 AM David Radley < > >> david_rad...@uk.ibm.com > >>>> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> I agree with Martijn that we only put features into version 2. Back > >>>>>> porting to v1 should not be business as usual for features, only > >> for > >>>>>> security and stability changes. > >>>>>> > >>>>>> If there is a maintainer willing to merge backported features to > >> v1, > >>> as > >>>>> it > >>>>>> is important to some part of the community, this should be allowed, > >>> as > >>>>>> different parts of the community have different priorities and > >>>> timelines, > >>>>>> Kind regards, David. > >>>>>> > >>>>>> > >>>>>> From: Alexander Fedulov <alexander.fedu...@gmail.com> > >>>>>> Date: Thursday, 23 May 2024 at 18:50 > >>>>>> To: dev@flink.apache.org <dev@flink.apache.org> > >>>>>> Subject: [EXTERNAL] Re: [DISCUSS] Proposing an LTS Release for the > >>> 1.x > >>>>> Line > >>>>>> Good point, Xintong, I incorporated this item into the FLIP. > >>>>>> > >>>>>> Best, > >>>>>> Alex > >>>>>> > >>>>>> On Wed, 22 May 2024 at 10:37, Xintong Song <tonysong...@gmail.com> > >>>>> wrote: > >>>>>> > >>>>>>> Thanks, Alex. > >>>>>>> > >>>>>>> I see one task that needs to be done once the FLIP is approved, > >>> which > >>>>> I'd > >>>>>>> suggest to also mention in the: To explain the LTS policy to > >> users > >>> on > >>>>>>> website / documentation (because FLIP is developer-facing) > >> before / > >>>>> upon > >>>>>>> releasing 1.20. > >>>>>>> > >>>>>>> Other than that, the FLIP LGTM. > >>>>>>> > >>>>>>> Best, > >>>>>>> > >>>>>>> Xintong > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov < > >>>>>>> alexander.fedu...@gmail.com> wrote: > >>>>>>> > >>>>>>>> Hi everyone, > >>>>>>>> > >>>>>>>> let's finalize this discussion. As Martijn suggested, I > >>> summarized > >>>>> this > >>>>>>>> thread into a FLIP [1]. Please take a look and let me know if > >>>> there’s > >>>>>>>> anything important that I might have missed. > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> Alex > >>>>>>>> > >>>>>>>> [1] https://cwiki.apache.org/confluence/x/BApeEg > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, 23 Jan 2024 at 03:30, Rui Fan <1996fan...@gmail.com> > >>>> wrote: > >>>>>>>> > >>>>>>>>> Thanks Martijn for the feedback! > >>>>>>>>> > >>>>>>>>> Sounds make sense to me! And I don't have strong opinion that > >>>> allow > >>>>>>>>> backporting new features to 1.x. > >>>>>>>>> > >>>>>>>>> Best, > >>>>>>>>> Rui > >>>>>>>>> > >>>>>>>>> On Mon, Jan 22, 2024 at 8:56 PM Martijn Visser < > >>>>>>> martijnvis...@apache.org > >>>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Hi Rui, > >>>>>>>>>> > >>>>>>>>>> I don't think that we should allow backporting of new > >>> features > >>>>> from > >>>>>>>>>> the first minor version of 2.x to 1.x. If a user doesn't > >> yet > >>>> want > >>>>>> to > >>>>>>>>>> upgrade to 2.0, I think that's fine since we'll have a LTS > >>> for > >>>>> 1.x. > >>>>>>> If > >>>>>>>>>> a newer feature becomes available in 2.x that's interesting > >>> for > >>>>> the > >>>>>>>>>> user, the user at that point can decide if they want to do > >>> the > >>>>>>>>>> migration. It's always a case-by-case tradeoff of effort vs > >>>>>> benefits, > >>>>>>>>>> and I think with a LTS version that has bug fixes only we > >>>> provide > >>>>>> the > >>>>>>>>>> users with assurance that existing bugs can get fixed, and > >>> that > >>>>>> they > >>>>>>>>>> can decide for themselves when they want to migrate to a > >>> newer > >>>>>>> version > >>>>>>>>>> with better/newer features. > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> > >>>>>>>>>> Martijn > >>>>>>>>>> > >>>>>>>>>> On Thu, Jan 11, 2024 at 3:50 AM Rui Fan < > >>> 1996fan...@gmail.com> > >>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Thanks everyone for discussing this topic! > >>>>>>>>>>> > >>>>>>>>>>> My question is could we make a trade-off between Flink > >>> users > >>>>>>>>>>> and Flink maintainers? > >>>>>>>>>>> > >>>>>>>>>>> 1. From the perspective of a Flink maintainer > >>>>>>>>>>> > >>>>>>>>>>> I strongly agree with Martin's point of view, such as: > >>>>>>>>>>> > >>>>>>>>>>> - Allowing backporting of new features to Flink 1.x will > >>>> result > >>>>>> in > >>>>>>>>> users > >>>>>>>>>>> delaying the upgrade. > >>>>>>>>>>> - New features will also introduce new bugs, meaning that > >>>>>>> maintainers > >>>>>>>>>> will > >>>>>>>>>>> have to spend time on two release versions. > >>>>>>>>>>> > >>>>>>>>>>> Considering the simplicity of maintenance, don't backport > >>>>>>>>>>> new features to Flink 1.x is fine. > >>>>>>>>>>> > >>>>>>>>>>> 2. From the perspective of a flink user > >>>>>>>>>>> > >>>>>>>>>>> In the first version Flink 2.x, flink will remove a lot > >> of > >>>>>>>>>>> deprecated api, and introduce some features. > >>>>>>>>>>> > >>>>>>>>>>> It's a new major version, major version changes are much > >>>>>>>>>>> greater than minor version and patch version. Big changes > >>>>>>>>>>> may introduce more bugs, so I guess that a large number > >>>>>>>>>>> of Flink users will not use the first version of 2.x in > >> the > >>>>>>>>>>> production environment. Maybe they will wait for the > >> second > >>>>>>>>>>> minor version of 2.x. > >>>>>>>>>>> > >>>>>>>>>>> So, I was wondering whether we allow backport new > >> features > >>>>>>>>>>> from the first minor version of 2.x to 1.x? > >>>>>>>>>>> > >>>>>>>>>>> It means, we allow backport new features of 2.0.0 to > >> 1.21. > >>>>>>>>>>> And 1.21.x is similar to 2.0.x, their features are same, > >>> but > >>>>>>>>>>> 2.0.x removes deprecated apis. After 2.0.0 is released, > >>>>>>>>>>> all new features in 2.1.x and above are only available in > >>>> 2.x. > >>>>>>>>>>> > >>>>>>>>>>> Looking forward to your opinions~ > >>>>>>>>>>> > >>>>>>>>>>> Best, > >>>>>>>>>>> Rui > >>>>>>>>>>> > >>>>>>>>>>> On Wed, Jan 10, 2024 at 9:39 PM Martijn Visser < > >>>>>>>>> martijnvis...@apache.org > >>>>>>>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi Alex, > >>>>>>>>>>>> > >>>>>>>>>>>> I saw that I missed replying to this topic. I do think > >>> that > >>>>>>> Xintong > >>>>>>>>>>>> touched on an important topic when he mentioned that we > >>>>> should > >>>>>>>> define > >>>>>>>>>>>> what an LTS version means. From my point of view, I > >> would > >>>>> state > >>>>>>>> that > >>>>>>>>>>>> an LTS version for Apache Flink means that bug fixes > >> only > >>>>> will > >>>>>> be > >>>>>>>>> made > >>>>>>>>>>>> available for a longer period of time. I think that, > >>>> combined > >>>>>>> with > >>>>>>>>>>>> what you called option 1 (a clear end-of-life date) is > >>> the > >>>>> best > >>>>>>>>>>>> option. > >>>>>>>>>>>> > >>>>>>>>>>>> Flink 2.0 will give us primarily the ability to remove > >> a > >>>> lot > >>>>> of > >>>>>>>>>>>> deprecated APIs, especially with Flink's deprecation > >>>>> strategy. > >>>>>> I > >>>>>>>>>>>> expect that the majority of users will have an easy > >>>> migration > >>>>>>> path > >>>>>>>>>>>> from a Flink 1.x to a Flink 2.0, if you're currently > >> not > >>>>> using > >>>>>> a > >>>>>>>>>>>> deprecated API and are a Java user. > >>>>>>>>>>>> > >>>>>>>>>>>> Allowing backporting of new features to Flink 1.x will > >>>> result > >>>>>> in > >>>>>>>>> users > >>>>>>>>>>>> delaying the upgrade, but it doesn't make the upgrade > >> any > >>>>>> easier > >>>>>>>> when > >>>>>>>>>>>> they must upgrade. New features will also introduce new > >>>> bugs, > >>>>>>>> meaning > >>>>>>>>>>>> that maintainers will have to spend time on two release > >>>>>> versions. > >>>>>>>> As > >>>>>>>>>>>> the codebases diverge more and more, this will just > >>> become > >>>>>>>>>>>> increasingly more complex. > >>>>>>>>>>>> > >>>>>>>>>>>> With that being said, I do think that it makes sense to > >>>> also > >>>>>>>>> formalize > >>>>>>>>>>>> the result of this discussion in a FLIP. That's just > >>> easier > >>>>> to > >>>>>>>> point > >>>>>>>>>>>> users towards at a later stage. > >>>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Martijn > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, Dec 4, 2023 at 9:55 PM Alexander Fedulov > >>>>>>>>>>>> <alexander.fedu...@gmail.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi everyone, > >>>>>>>>>>>>> > >>>>>>>>>>>>> As we progress with the 1.19 release, which might > >>>>> potentially > >>>>>>>>>> (although > >>>>>>>>>>>> not > >>>>>>>>>>>>> likely) be the last in the 1.x line, I'd like to > >> revive > >>>> our > >>>>>>>>>> discussion on > >>>>>>>>>>>>> the > >>>>>>>>>>>>> LTS support matter. There is a general consensus that > >>> due > >>>>> to > >>>>>>>>>> breaking API > >>>>>>>>>>>>> changes in 2.0, extending bug fixes support by > >>>> designating > >>>>> an > >>>>>>> LTS > >>>>>>>>>> release > >>>>>>>>>>>>> is > >>>>>>>>>>>>> something we want to do. > >>>>>>>>>>>>> > >>>>>>>>>>>>> To summarize, the approaches we've considered are: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Time-based: The last release of the 1.x line gets a > >>> clear > >>>>>>>>> end-of-life > >>>>>>>>>>>> date > >>>>>>>>>>>>> (2 years). > >>>>>>>>>>>>> Release-based: The last release of the 1.x line gets > >>>>> support > >>>>>>> for > >>>>>>>> 4 > >>>>>>>>>> minor > >>>>>>>>>>>>> releases in the 2.x line. The exact time is unknown, > >>> but > >>>> we > >>>>>>>> assume > >>>>>>>>>> it to > >>>>>>>>>>>> be > >>>>>>>>>>>>> roughly 2 years. > >>>>>>>>>>>>> LTS-to-LTS release: The last release of the 1.x line > >> is > >>>>>>> supported > >>>>>>>>>> until > >>>>>>>>>>>> the > >>>>>>>>>>>>> last release in the 2.x line is designated as LTS. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We need to strike a balance between being > >> user-friendly > >>>> and > >>>>>>>> nudging > >>>>>>>>>>>> people > >>>>>>>>>>>>> to > >>>>>>>>>>>>> upgrade. From that perspective, option 1 is my > >>> favorite - > >>>>> we > >>>>>>> all > >>>>>>>>> know > >>>>>>>>>>>> that > >>>>>>>>>>>>> having a clear deadline works wonders in motivating > >>>> action. > >>>>>> At > >>>>>>>> the > >>>>>>>>>> same > >>>>>>>>>>>>> time, > >>>>>>>>>>>>> I appreciate that we might not want to introduce new > >>>> kinds > >>>>> of > >>>>>>>>>> procedures, > >>>>>>>>>>>>> so > >>>>>>>>>>>>> option 2 would be my second choice, provided we also > >>>>>> formulate > >>>>>>> it > >>>>>>>>>> like "4 > >>>>>>>>>>>>> minor releases, at least 2 years" (in case the minor > >>>>> release > >>>>>>>>> cadence > >>>>>>>>>>>>> accelerates for some reason). I find option 3 a bit > >>>>>> problematic > >>>>>>>>>> since it > >>>>>>>>>>>>> gives no incentive to upgrade, and people who do not > >>>> follow > >>>>>>> Flink > >>>>>>>>>>>>> development > >>>>>>>>>>>>> closely might be caught by surprise when we decide to > >>>> bump > >>>>>> the > >>>>>>>>> major > >>>>>>>>>>>>> version > >>>>>>>>>>>>> again. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'd like to open a vote to stamp the official > >> decision, > >>>> but > >>>>>>>> first, > >>>>>>>>> I > >>>>>>>>>>>> would > >>>>>>>>>>>>> like to understand if we can reach consensus on one > >> of > >>>> the > >>>>>>>> options > >>>>>>>>>> here, > >>>>>>>>>>>> or > >>>>>>>>>>>>> if > >>>>>>>>>>>>> we'll need to push that to a vote by presenting > >>> multiple > >>>>>>> options. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Looking forward to hearing your thoughts on this > >>> matter. > >>>>>>>>>>>>> > >>>>>>>>>>>>> P.S.: 1.x and 2.x are just examples in this case; the > >>>>>> decision > >>>>>>>> also > >>>>>>>>>>>>> translates > >>>>>>>>>>>>> into a procedure for future major releases. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best, > >>>>>>>>>>>>> Alex > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, 27 Jul 2023 at 17:32, Jing Ge > >>>>>>> <j...@ververica.com.invalid > >>>>>>>>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Konstantin, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> What you said makes sense. Dropping modules is an > >>>>> efficient > >>>>>>>>> option > >>>>>>>>>> to > >>>>>>>>>>>>>> accelerate Flink evolution with acceptable function > >>>>>>>> regressions. > >>>>>>>>> We > >>>>>>>>>>>> should > >>>>>>>>>>>>>> do it constantly and strategically. On the other > >>> hand, > >>>> we > >>>>>>>> should > >>>>>>>>>> point > >>>>>>>>>>>> out > >>>>>>>>>>>>>> the core modules that must be backward compatible > >>> when > >>>> a > >>>>>> new > >>>>>>>>> major > >>>>>>>>>>>> version > >>>>>>>>>>>>>> is released. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Jing > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl > >>>>>>>>>>>>>> <matthias.p...@aiven.io.invalid> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> @Mathias, I am not quite sure about the 3 > >>> versions > >>>>>>>>> description. > >>>>>>>>>>>> Are you > >>>>>>>>>>>>>>>> concerned that 1.x and 2.x LTS releases could > >>>>> overlap, > >>>>>> if > >>>>>>>> 3.0 > >>>>>>>>>> comes > >>>>>>>>>>>>>>> early? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yes. Maybe, that's only a theoretical scenario. > >> It > >>>>>> wouldn't > >>>>>>>>> work > >>>>>>>>>> if > >>>>>>>>>>>> we go > >>>>>>>>>>>>>>> with your suggestion to use "proper time" rather > >>> than > >>>>>>> release > >>>>>>>>>> cycles > >>>>>>>>>>>> to > >>>>>>>>>>>>>>> define the length of a support period (which > >> sounds > >>>>>>>>> reasonable). > >>>>>>>>>> My > >>>>>>>>>>>>>> concern > >>>>>>>>>>>>>>> was that we get into a situation where we need to > >>>>> support > >>>>>>>> four > >>>>>>>>>>>> versions > >>>>>>>>>>>>>> of > >>>>>>>>>>>>>>> Flink. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed, Jul 26, 2023 at 4:21 PM Alexander > >> Fedulov < > >>>>>>>>>>>>>>> alexander.fedu...@gmail.com> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The question is if we want to tie the release > >>> cycle > >>>>> of > >>>>>>> 2.x > >>>>>>>> to > >>>>>>>>>> how > >>>>>>>>>>>> much > >>>>>>>>>>>>>>> time > >>>>>>>>>>>>>>>> we give our users to migrate. And "time" is a > >>>>> critical > >>>>>>> word > >>>>>>>>>> here. > >>>>>>>>>>>> I can > >>>>>>>>>>>>>>> see > >>>>>>>>>>>>>>>> us > >>>>>>>>>>>>>>>> potentially wanting to iterate on the 2.x line > >>> more > >>>>>>>> rapidly, > >>>>>>>>>>>> because of > >>>>>>>>>>>>>>> all > >>>>>>>>>>>>>>>> of the > >>>>>>>>>>>>>>>> major changes, until the cycles get settled to > >> a > >>>>>> typical > >>>>>>>>>> cadence > >>>>>>>>>>>> again. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> This means that user's won't know how much time > >>>> they > >>>>>>> would > >>>>>>>>>> have to > >>>>>>>>>>>>>>> actually > >>>>>>>>>>>>>>>> migrate off of 1.x. And I can see this > >> knowledge > >>>>> being > >>>>>>>>>> critical for > >>>>>>>>>>>>>>>> companies' > >>>>>>>>>>>>>>>> quarterly/yearly plannings, so transparency > >> here > >>> is > >>>>>> key. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> That's why I think it makes sense to deviate > >> from > >>>> the > >>>>>>>>> typical N > >>>>>>>>>>>> minor > >>>>>>>>>>>>>>>> releases > >>>>>>>>>>>>>>>> rule and set an explicit time period. We > >> usually > >>>>> have a > >>>>>>>> minor > >>>>>>>>>>>> release > >>>>>>>>>>>>>>> every > >>>>>>>>>>>>>>>> four > >>>>>>>>>>>>>>>> months, so my proposition would be to > >> designate a > >>>> 1.5 > >>>>>>> years > >>>>>>>>>> period > >>>>>>>>>>>> as > >>>>>>>>>>>>>>>> a generous approximation of a 4 releases cycle. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I also agree with limiting support to bugfixes > >> - > >>>>> Flink > >>>>>> is > >>>>>>>> at > >>>>>>>>>> the > >>>>>>>>>>>> level > >>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>> maturity where > >>>>>>>>>>>>>>>> I believe nothing so critical will be missing > >> in > >>>> the > >>>>>>> last > >>>>>>>>> 1.x > >>>>>>>>>>>> release > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>> we'd need to > >>>>>>>>>>>>>>>> backport if from 2.x. In the end, we want to > >>>>> encourage > >>>>>>>> users > >>>>>>>>> to > >>>>>>>>>>>>>> migrate. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> @Mathias, I am not quite sure about the 3 > >>> versions > >>>>>>>>> description. > >>>>>>>>>>>> Are you > >>>>>>>>>>>>>>>> concerned that 1.x and 2.x LTS releases could > >>>>> overlap, > >>>>>> if > >>>>>>>> 3.0 > >>>>>>>>>> comes > >>>>>>>>>>>>>>> early? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>> Alex > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Wed, 26 Jul 2023 at 14:47, Matthias Pohl < > >>>>>>>>>>>> matthias.p...@aiven.io > >>>>>>>>>>>>>>>> .invalid> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> Unless otherwise stated above: > >>>>>> > >>>>>> IBM United Kingdom Limited > >>>>>> Registered in England and Wales with number 741598 > >>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 > >>> 3AU > >>>>>> > >>>>> > >>>> > >>>> Unless otherwise stated above: > >>>> > >>>> IBM United Kingdom Limited > >>>> Registered in England and Wales with number 741598 > >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 > 3AU > >>>> > >>> > >> > >
