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