Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Hi Ufuk, thanks for your feedback, it seems we are in sync about all major points. @everyone: I expanded the FLIP with a short LTS policy description that we will later add to the docs: *Long-Term Support (LTS) Policy:* Since major versions typically introduce breaking changes, the final minor release of each major version line is designated as a Long-Term Support (LTS) version. Supported for a fixed period of two years with only bug fixes and security updates, these LTS versions provide a stable and predictable timeframe for preparing and transitioning to the next major Apache Flink release. Please let me know if you think it misses something. I will start a voting thread shortly. Best, Alex On Wed, 12 Jun 2024 at 22:51, Ufuk Celebi wrote: > Hi folks! > > 1) Big +1 on being strict with limiting the LTS version to patches and no > feature backports. I think that it would open up a big can of worms. What > does it even mean to backport a feature to a LTS version? My understanding > is that we want to designate a single 1.x version as LTS. But if we > backport a feature, we would technically need to bump the minor version and > then we are basically back at maintaining features for 1.x. Let me know if > I’m misunderstanding something. > > 2) It also seems fine to me to stick to 1.x and 2.x concretely in the FLIP > since it’ll be our first LTS version and we don’t anticipate (as of today) > many overlapping LTS versions. It actually makes it clearer to me what > we’re talking about. > > 3) 2 years seems like a good starting point to me. If anything, I’m > wondering whether it should be longer given that there are many users on > old versions even today. It’s probably best to stick to this number and > expand if needed down the line (as opposed to starting with a longer > duration and then running into problems). > > Cheers, > > Ufuk > > > On 11. Jun 2024, at 15:44, Alexander Fedulov < > alexander.fedu...@gmail.com> wrote: > > > > Hi Matthias, > > > > I think we can include this generic semantic into the writeup of the LTS > > definition for the Flink website (last item in the Migration Plan). > > Talking about 1.x and 2.x feels more natural than about N.x and N+1.x - > I'd > > prefer not to overcomplicate things here. > > Should the gap before the next major release match this one (eight > years), > > it would be appropriate to reconsider the project stance and vote anew if > > required. > > > > Best, > > Alex > > > > On Mon, 27 May 2024 at 09:02, Matthias Pohl wrote: > > > >> Hi Alex, > >> thanks for creating the FLIP. One question: Is it intentionally done > that > >> the FLIP only covers the 1.x LTS version? Why don't we make the FLIP > >> generic to also apply to other major version upgrades? > >> > >> Best, > >> Matthias > >> > >> On Sat, May 25, 2024 at 4:55 PM Xintong Song > >> 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 > >>> 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 > >>>> Date: Friday, 24 May 2024 at 14:07 > >>>> To: 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Hi folks! 1) Big +1 on being strict with limiting the LTS version to patches and no feature backports. I think that it would open up a big can of worms. What does it even mean to backport a feature to a LTS version? My understanding is that we want to designate a single 1.x version as LTS. But if we backport a feature, we would technically need to bump the minor version and then we are basically back at maintaining features for 1.x. Let me know if I’m misunderstanding something. 2) It also seems fine to me to stick to 1.x and 2.x concretely in the FLIP since it’ll be our first LTS version and we don’t anticipate (as of today) many overlapping LTS versions. It actually makes it clearer to me what we’re talking about. 3) 2 years seems like a good starting point to me. If anything, I’m wondering whether it should be longer given that there are many users on old versions even today. It’s probably best to stick to this number and expand if needed down the line (as opposed to starting with a longer duration and then running into problems). Cheers, Ufuk > On 11. Jun 2024, at 15:44, Alexander Fedulov > wrote: > > Hi Matthias, > > I think we can include this generic semantic into the writeup of the LTS > definition for the Flink website (last item in the Migration Plan). > Talking about 1.x and 2.x feels more natural than about N.x and N+1.x - I'd > prefer not to overcomplicate things here. > Should the gap before the next major release match this one (eight years), > it would be appropriate to reconsider the project stance and vote anew if > required. > > Best, > Alex > > On Mon, 27 May 2024 at 09:02, Matthias Pohl wrote: > >> Hi Alex, >> thanks for creating the FLIP. One question: Is it intentionally done that >> the FLIP only covers the 1.x LTS version? Why don't we make the FLIP >> generic to also apply to other major version upgrades? >> >> Best, >> Matthias >> >> On Sat, May 25, 2024 at 4:55 PM Xintong Song >> 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 >>> 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 >>>> Date: Friday, 24 May 2024 at 14:07 >>>> To: 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 >> >>>> 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 differen
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Hi Matthias, I think we can include this generic semantic into the writeup of the LTS definition for the Flink website (last item in the Migration Plan). Talking about 1.x and 2.x feels more natural than about N.x and N+1.x - I'd prefer not to overcomplicate things here. Should the gap before the next major release match this one (eight years), it would be appropriate to reconsider the project stance and vote anew if required. Best, Alex On Mon, 27 May 2024 at 09:02, Matthias Pohl wrote: > Hi Alex, > thanks for creating the FLIP. One question: Is it intentionally done that > the FLIP only covers the 1.x LTS version? Why don't we make the FLIP > generic to also apply to other major version upgrades? > > Best, > Matthias > > On Sat, May 25, 2024 at 4:55 PM Xintong Song > 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 > > 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 > > > Date: Friday, 24 May 2024 at 14:07 > > > To: 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 > > > > 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 > > >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > 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 > > Date: Friday, 24 May 2024 at 14:07 > > To: 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 > > 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 > > > > 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 > > > > Date: Thursday, 23 May 2024 at 18:50 > > > > To: 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 > > > 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 >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
> > 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 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 > Date: Friday, 24 May 2024 at 14:07 > To: 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 > 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 > > 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 > > > Date: Thursday, 23 May 2024 at 18:50 > > > To: 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 > > 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. > > > > > > > > > > B
RE: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 Date: Friday, 24 May 2024 at 14:07 To: 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 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 > 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 > > Date: Thursday, 23 May 2024 at 18:50 > > To: 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 > 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
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 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 > 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 > > Date: Thursday, 23 May 2024 at 18:50 > > To: 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 > 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 alwa
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > Date: Thursday, 23 May 2024 at 18:50 > To: 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 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: > > > > > > > > > > > > - All
RE: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 Date: Thursday, 23 May 2024 at 18:50 To: 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 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. > > > > > >
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 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. >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 > > > 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 > > > > >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 > 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 > > > > 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > > > 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 > > > 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 > 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 > > 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > 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 > wrote: > >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 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 > > 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
Re: Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Hi Julian, Could you please remove the duplicated "RE:" in the topic of the reply? That way we can continue this discussion to the original thread. (Apache deals with it correctly, but not all email clients/services do, e.g. GMail) Thanks, Alex On Tue, 5 Dec 2023 at 09:39, Payne, Julian wrote: > Hey all, > Thanks for this proposal, I think it makes a lot of sense. I am, curious > to know what time horizon we would consider for LTS of 1.x. Customers value > knowing when versions will deprecate so they can build migration into their > planning and resourcing cycles, so I would be in favour of being > transparent on how long the community will support 1.x. > > Thanks > > > Julian > > On 2023/07/26 14:16:43 Konstantin Knauf wrote: > > Hi Jing, > > > > > How could we help users and avoid this happening? > > > > I don't think we will be able to avoid this in all cases. And I think > > that's ok. Its always a trade-off between supporting new use cases and > > moving the project forward and backwards compatibility (in a broad > sense). > > For example, we dropped Mesos support in a minor release in the past. If > > you're only option for running Flink was Mesos, you were stuck on Flink > > 1.13 or so. > > > > So, I think, it is in the end a case-by-case decision. How big is the > cost > > of continued support a "legacy feature/system" and how many users are > > affected to which degree by dropping it? > > > > Best, > > > > Konstantin > > > > > > Am Di., 25. Juli 2023 um 18:34 Uhr schrieb Jing Ge > > : > > > > > 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 > > > 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 > > > > : > > > > > > > > > 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
RE: Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Hey all, Thanks for this proposal, I think it makes a lot of sense. I am, curious to know what time horizon we would consider for LTS of 1.x. Customers value knowing when versions will deprecate so they can build migration into their planning and resourcing cycles, so I would be in favour of being transparent on how long the community will support 1.x. Thanks Julian On 2023/07/26 14:16:43 Konstantin Knauf wrote: > Hi Jing, > > > How could we help users and avoid this happening? > > I don't think we will be able to avoid this in all cases. And I think > that's ok. Its always a trade-off between supporting new use cases and > moving the project forward and backwards compatibility (in a broad sense). > For example, we dropped Mesos support in a minor release in the past. If > you're only option for running Flink was Mesos, you were stuck on Flink > 1.13 or so. > > So, I think, it is in the end a case-by-case decision. How big is the cost > of continued support a "legacy feature/system" and how many users are > affected to which degree by dropping it? > > Best, > > Konstantin > > > Am Di., 25. Juli 2023 um 18:34 Uhr schrieb Jing Ge > : > > > 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 > > 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 > > > : > > > > > > > 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > 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 > > .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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > .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 > > > 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 > > > > wrote: > > > > > > > > > Hi Jing, > > > > > > > > > > let's not overindex on the Source-/SinkFunction discussion in this > > > > thread. > > > > > > > > > > We will generally drop/break a lot of APIs
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
I'm actually thinking about supporting the LTS release until the next LTS / major version bump. E.g., if 1.19 is a LTS, we provide support for it for the entire 2.x series, until we bump to 3.0 and make the last 2.x minor release the new LTS. This probably will not require much more effort than the 4 minor release support. If we only backport the bug fixes but no new features, I'd expect the LTS version to be quite stable after 4 minor release cycles, and there are likely very few bug fixes that still apply to it. That means benefiting users who need longer support with a very low price. But one can also argue that we do not want to provide as long support as possible, in order to encourage users to upgrade. So I'm also fine with the 4-minor release period. I'm not a big fan of setting an explicit time period. Having two different rules (release-cycle based regular minor version support, and time-based LTS version support) sounds unnecessarily complicated. I'm not concerned that the support period is not accurate enough. The period is only a minimum guarantee. As mentioned in our update policy [1], the community is open to discuss bugfix releases for versions that are "not supported". In fact, it is not rare that we provide bugfix releases that are more than 2 minor versions behind the latest, as requested by users. Best, Xintong [1] https://flink.apache.org/downloads/#update-policy-for-old-releases On Wed, Jul 26, 2023 at 10:53 PM Matthias Pohl 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 > .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 > > > 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
> > @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 .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 > > 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 > > > 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > 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 > > 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 > > > : > > > > > > > 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Hi Jing, > How could we help users and avoid this happening? I don't think we will be able to avoid this in all cases. And I think that's ok. Its always a trade-off between supporting new use cases and moving the project forward and backwards compatibility (in a broad sense). For example, we dropped Mesos support in a minor release in the past. If you're only option for running Flink was Mesos, you were stuck on Flink 1.13 or so. So, I think, it is in the end a case-by-case decision. How big is the cost of continued support a "legacy feature/system" and how many users are affected to which degree by dropping it? Best, Konstantin Am Di., 25. Juli 2023 um 18:34 Uhr schrieb Jing Ge : > 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 > 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 > > : > > > > > 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 > > > > wrote: > > > > > > > > >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > 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 > > : > > > > > 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > : > > > 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 > > > 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 > > > 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 >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 : > 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 > 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 > > 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 > 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 >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > 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 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 > > > > > > > > > > > > > >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 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 >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
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 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 > >
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
+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 > 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
