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 <matthias.p...@aiven.io.invalid> wrote: > > > > @Mathias, I am not quite sure about the 3 versions description. Are you > > concerned that 1.x and 2.x LTS releases could overlap, if 3.0 comes > early? > > Yes. Maybe, that's only a theoretical scenario. It wouldn't work if we go > with your suggestion to use "proper time" rather than release cycles to > define the length of a support period (which sounds reasonable). My concern > was that we get into a situation where we need to support four versions of > Flink. > > On Wed, Jul 26, 2023 at 4:21 PM Alexander Fedulov < > alexander.fedu...@gmail.com> wrote: > > > The question is if we want to tie the release cycle of 2.x to how much > time > > we give our users to migrate. And "time" is a critical word here. I can > see > > us > > potentially wanting to iterate on the 2.x line more rapidly, because of > all > > of the > > major changes, until the cycles get settled to a typical cadence again. > > > > This means that user's won't know how much time they would have to > actually > > migrate off of 1.x. And I can see this knowledge being critical for > > companies' > > quarterly/yearly plannings, so transparency here is key. > > > > That's why I think it makes sense to deviate from the typical N minor > > releases > > rule and set an explicit time period. We usually have a minor release > every > > four > > months, so my proposition would be to designate a 1.5 years period as > > a generous approximation of a 4 releases cycle. > > > > I also agree with limiting support to bugfixes - Flink is at the level of > > maturity where > > I believe nothing so critical will be missing in the last 1.x release > that > > we'd need to > > backport if from 2.x. In the end, we want to encourage users to migrate. > > > > @Mathias, I am not quite sure about the 3 versions description. Are you > > concerned that 1.x and 2.x LTS releases could overlap, if 3.0 comes > early? > > > > Best, > > Alex > > > > On Wed, 26 Jul 2023 at 14:47, Matthias Pohl <matthias.p...@aiven.io > > .invalid> > > wrote: > > > > > I think making the last minor release before a major release an LTS > > release > > > with extended support makes sense. I cannot think of a reason against > the > > > four minor release cycles suggested by Marton. Only providing bug fixes > > and > > > not allowing features to be backported sounds reasonable to keep the > > > maintenance costs low. > > > > > > And maybe we can make this a general convention for last minor releases > > for > > > > all major releases, rather than only discuss it for the 2.0 version > > bump. > > > > > > > > > I guess we should also make it explicit that we only support one LTS > > > version to reduce the number of supported versions to 3 (x.y, x.[y-1], > > > [x-1].z). I have the impression that this is implied by everyone. I > > wanted > > > to mention this as an additional item, anyway. ...even though it would > > only > > > become a topic when discussing 3.0. > > > > > > Matthias > > > > > > On Tue, Jul 25, 2023 at 6:33 PM Jing Ge <j...@ververica.com.invalid> > > > wrote: > > > > > > > Hi Konstantin, > > > > > > > > I might have not made myself clear enough, apologies. The > > > > source-/sink-function was used as a concrete example to discuss the > > > pattern > > > > before we decided to offer LTS. The intention was not to hijack this > > > thread > > > > to discuss how to deprecate them. > > > > > > > > We all wish that the only thing users need to migrate from Flink 1.x > to > > > 2.0 > > > > is some code changes in their repos and we all wish users will > migrate, > > > if > > > > LTS has long enough support time. But the question I tried to discuss > > is > > > > not the wish but the "How?". We might be able to toss the high > > migration > > > > effort aside(we shouldn't), since it is theoretically still doable if > > > users > > > > have long enough time, even if the effort is extremely high. Another > > > > concern is that if "function regressions" is allowed in 2.0, i.e. if > > 2.0 > > > > has a lack of functionalities or bugs compared to 1.x, there will be > no > > > way > > > > for users to do the migration regardless of whether we encourage them > > to > > > > migrate or they haven been given enough time(how long is enough?) > > because > > > > LTS has been offered. How could we help users and avoid this > happening? > > > > > > > > Best regards, > > > > Jing > > > > > > > > On Tue, Jul 25, 2023 at 6:57 PM Konstantin Knauf <kna...@apache.org> > > > > wrote: > > > > > > > > > Hi Jing, > > > > > > > > > > let's not overindex on the Source-/SinkFunction discussion in this > > > > thread. > > > > > > > > > > We will generally drop/break a lot of APIs in Flink 2.0. So, > > naturally > > > > > users will need to make more changes to their code in order to > > migrate > > > > from > > > > > 1.x to Flink 2.0. In order to give them more time to do this, we > > > support > > > > > the last Flink 1.x release for a longer time with bug fix releases. > > > > > > > > > > Of course, we still encourage users to migrate to Flink 2.0, > because > > at > > > > > some point, we will stop support Flink 1.x. For example, if we > > followed > > > > > Marton's proposal we would support Flink 1.x LTS for about 2 years > > > > (roughly > > > > > 4 minor release cycles) instead of about 1 year (2 minor release > > > cycles) > > > > > for regular minor releases. This seems like a reasonable timeframe > to > > > me. > > > > > It also gives us more time to discover and address blockers in > > > migrating > > > > to > > > > > Flink 2.x that we are not aware of right now. > > > > > > > > > > Best, > > > > > > > > > > Konstantin > > > > > > > > > > Am Di., 25. Juli 2023 um 12:48 Uhr schrieb Jing Ge > > > > > <j...@ververica.com.invalid>: > > > > > > > > > > > Hi all, > > > > > > > > > > > > Overall, it is a good idea to provide the LTS release, but I'd > like > > > to > > > > > > reference a concrete case as an example to understand what > > > restrictions > > > > > the > > > > > > LTS should have. > > > > > > > > > > > > Hypothetically, Source-/Sink- Function have been deprecated in > 1.x > > > LTS > > > > > and > > > > > > removed in 2.0 and the issues[1] are not solved in 2.0. This is a > > > > typical > > > > > > scenario that the old APIs are widely used in 1.x LTS and the new > > > APIs > > > > in > > > > > > 2.0 are not ready yet to take over all users. We will have the > > > > following > > > > > > questions: > > > > > > > > > > > > 1. Is this scenario allowed at all? Do we all agree that there > > could > > > be > > > > > > some features/functionalities that only work in 1.x LTS after 2.0 > > has > > > > > been > > > > > > released? > > > > > > 2. How long are we going to support 1.x LTS? 1 year? 2 years? As > > long > > > > as > > > > > > the issues that block users from migrating to 2.0 are not solved, > > we > > > > > can't > > > > > > stop the LTS support, even if the predefined support time > expires. > > > > > > 3. What is the intention to release a new version with (or > without) > > > > LTS? > > > > > Do > > > > > > we still want to engage users to migrate to the new release asap? > > If > > > > the > > > > > > old APIs 1.x LTS offer more than the new APIs in 2.0 or it is > > almost > > > > > > impossible to migrate, double effort will be required to maintain > > > those > > > > > > major releases for a very long time. We will be facing many > > cohorts. > > > > > > > > > > > > IMHO, we should be clear with those questions before we start > > talking > > > > > about > > > > > > LTS. WDYT? > > > > > > > > > > > > Best regards, > > > > > > Jing > > > > > > > > > > > > > > > > > > [1] > > https://lists.apache.org/thread/734zhkvs59w2o4d1rsnozr1bfqlr6rgm > > > > > > > > > > > > On Tue, Jul 25, 2023 at 6:08 PM Márton Balassi < > > > > balassi.mar...@gmail.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi team, > > > > > > > > > > > > > > +1 for supporting the last 1.x for a longer than usual period > of > > > time > > > > > and > > > > > > > limiting it to bugfixes. I would suggest supporting it for > double > > > the > > > > > > usual > > > > > > > amount of time (4 minor releases). > > > > > > > > > > > > > > On Tue, Jul 25, 2023 at 9:25 AM Konstantin Knauf < > > > kna...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > yes, I think, it makes sense to support the last 1.x release > > > longer > > > > > > than > > > > > > > > usual. This should be limited to bugfixes in my opinion. > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > Konstantin > > > > > > > > > > > > > > > > Am Di., 25. Juli 2023 um 07:07 Uhr schrieb Xintong Song < > > > > > > > > tonysong...@gmail.com>: > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > Providing a longer supporting period for the last 1.x minor > > > > release > > > > > > > makes > > > > > > > > > sense to me. > > > > > > > > > > > > > > > > > > I think we need to be more specific about what LTS means > > here. > > > > > > > > > > > > > > > > > > - IIUC, that means for the last 1.x minor release, we > will > > > > keep > > > > > > > > > providing 1.x.y / 1.x.z bugfix release. This is a > stronger > > > > > support > > > > > > > > > compared > > > > > > > > > to regular minor releases which by default are only > > > supported > > > > > for > > > > > > 2 > > > > > > > > > minor > > > > > > > > > release cycles. > > > > > > > > > - Do we only provide bug fixes for the LTS release, or > do > > we > > > > > also > > > > > > > > allow > > > > > > > > > backporting features to that release? > > > > > > > > > - How long exactly shall we support the LTS release? > > > > > > > > > > > > > > > > > > And maybe we can make this a general convention for last > > minor > > > > > > releases > > > > > > > > for > > > > > > > > > all major releases, rather than only discuss it for the 2.0 > > > > version > > > > > > > bump. > > > > > > > > > > > > > > > > > > @Leonard, > > > > > > > > > > > > > > > > > > I'd like to clarify that there are no community decisions > yet > > > on > > > > > > > release > > > > > > > > > 2.0 after 1.19. It is possible to have 1.20 before 2.0. > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > Xintong > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 25, 2023 at 11:54 AM Leonard Xu < > > xbjt...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > +1, it’s pretty necessary especially we deprecated so > many > > > APIs > > > > > in > > > > > > > 1.18 > > > > > > > > > > and plan to remove in 2.0. > > > > > > > > > > > > > > > > > > > > The 1.19 should be a proper version for LTS Release. > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > Leonard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Jul 25, 2023, at 3:30 AM, Alexander Fedulov < > > > > > > > > > > alexander.fedu...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > > > > > > > > > > > Recently, there were a lot of discussions about the > > > > deprecation > > > > > > of > > > > > > > > > > various > > > > > > > > > > > APIs for the upcoming 2.0 release. It appears there are > > two > > > > > main > > > > > > > > > > motivations > > > > > > > > > > > with opposing directions, causing these discussions to > > > remain > > > > > > > > > unsettled. > > > > > > > > > > On > > > > > > > > > > > one hand, there's a desire to finally trim a wide range > > of > > > > > legacy > > > > > > > > APIs, > > > > > > > > > > some > > > > > > > > > > > lingering around since the beginning of the 1.x release > > > line > > > > > (as > > > > > > > far > > > > > > > > > > back as > > > > > > > > > > > 2016). On the other hand, there is a commitment to > uphold > > > our > > > > > > > > > guarantees > > > > > > > > > > to > > > > > > > > > > > the users, ensuring a smooth transition. > > > > > > > > > > > > > > > > > > > > > > I believe we could reconcile these two motivations. My > > > > > > proposition > > > > > > > is > > > > > > > > > to > > > > > > > > > > > designate the final release of the 1.x timeline as a > > > > Long-Term > > > > > > > > Support > > > > > > > > > > (LTS) > > > > > > > > > > > release. By doing so, we would: > > > > > > > > > > > > > > > > > > > > > > 1. Enable more efficient cleanup and be liberated to > > > > introduce > > > > > > more > > > > > > > > > > breaking > > > > > > > > > > > changes, paving the way for greater innovation in the > > 2.0 > > > > > > > release. > > > > > > > > > > > 2. Sustain a positive user experience by granting > enough > > > time > > > > > for > > > > > > > the > > > > > > > > > > > changes > > > > > > > > > > > introduced in 2.0 to stabilize, allowing users to > > > > confidently > > > > > > > > > > transition > > > > > > > > > > > their production code to the new release. > > > > > > > > > > > > > > > > > > > > > > I look forward to hearing your thoughts on this > proposal. > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > https://twitter.com/snntrable > > > > > > > > https://github.com/knaufk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > https://twitter.com/snntrable > > > > > https://github.com/knaufk > > > > > > > > > > > > > > >
