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