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 >>>> >>> >>
