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