You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Alexander Fedulov <al...@gmail.com> on 2024/05/21 09:20:56 UTC
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 <19...@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 <ma...@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 <19...@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 <
> martijnvisser@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
> > > > <al...@gmail.com> wrote:
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > As we progress with the 1.19 release, which might potentially
> > (although
> > > > not
> > > > > likely) be the last in the 1.x line, I'd like to revive our
> > discussion on
> > > > > the
> > > > > LTS support matter. There is a general consensus that due to
> > breaking API
> > > > > changes in 2.0, extending bug fixes support by designating an LTS
> > release
> > > > > is
> > > > > something we want to do.
> > > > >
> > > > > To summarize, the approaches we've considered are:
> > > > >
> > > > > Time-based: The last release of the 1.x line gets a clear
> end-of-life
> > > > date
> > > > > (2 years).
> > > > > Release-based: The last release of the 1.x line gets support for 4
> > minor
> > > > > releases in the 2.x line. The exact time is unknown, but we assume
> > it to
> > > > be
> > > > > roughly 2 years.
> > > > > LTS-to-LTS release: The last release of the 1.x line is supported
> > until
> > > > the
> > > > > last release in the 2.x line is designated as LTS.
> > > > >
> > > > > We need to strike a balance between being user-friendly and nudging
> > > > people
> > > > > to
> > > > > upgrade. From that perspective, option 1 is my favorite - we all
> know
> > > > that
> > > > > having a clear deadline works wonders in motivating action. At the
> > same
> > > > > time,
> > > > > I appreciate that we might not want to introduce new kinds of
> > procedures,
> > > > > so
> > > > > option 2 would be my second choice, provided we also formulate it
> > like "4
> > > > > minor releases, at least 2 years" (in case the minor release
> cadence
> > > > > accelerates for some reason). I find option 3 a bit problematic
> > since it
> > > > > gives no incentive to upgrade, and people who do not follow Flink
> > > > > development
> > > > > closely might be caught by surprise when we decide to bump the
> major
> > > > > version
> > > > > again.
> > > > >
> > > > > I'd like to open a vote to stamp the official decision, but first,
> I
> > > > would
> > > > > like to understand if we can reach consensus on one of the options
> > here,
> > > > or
> > > > > if
> > > > > we'll need to push that to a vote by presenting multiple options.
> > > > >
> > > > > Looking forward to hearing your thoughts on this matter.
> > > > >
> > > > > P.S.: 1.x and 2.x are just examples in this case; the decision also
> > > > > translates
> > > > > into a procedure for future major releases.
> > > > >
> > > > > Best,
> > > > > Alex
> > > > >
> > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge <ji...@ververica.com.invalid>
> > > > wrote:
> > > > >
> > > > > > Hi Konstantin,
> > > > > >
> > > > > > What you said makes sense. Dropping modules is an efficient
> option
> > to
> > > > > > accelerate Flink evolution with acceptable function regressions.
> We
> > > > should
> > > > > > do it constantly and strategically. On the other hand, we should
> > point
> > > > out
> > > > > > the core modules that must be backward compatible when a new
> major
> > > > version
> > > > > > is released.
> > > > > >
> > > > > > Best regards,
> > > > > > Jing
> > > > > >
> > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > <ma...@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.fedulov@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.pohl@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
> > > > <ji...@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 <
> > > > > > knaufk@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
> > > > > > > > > > > <ji...@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.marton@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 <
> > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > xbjtdcq@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.fedulov@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
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
>
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Alexander Fedulov <al...@gmail.com>.
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 <uc...@apache.org> 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.fedulov@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 <ma...@apache.org> 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 <to...@gmail.com>
> >> wrote:
> >>
> >>>>
> >>>> I think our starting point should be "We don't backport features,
> >> unless
> >>>> discussed and agreed on the Dev mailing list".
> >>>
> >>>
> >>> This makes perfect sense. In general, I think we want to encourage
> users
> >> to
> >>> upgrade in order to use the new features. Alternatively, users can also
> >>> choose to maintain their own custom patches based on the LTS version. I
> >>> personally don't see why backporting new features to old releases is
> >>> necessary. In case of exceptions, a mailing list discussion is always a
> >>> good direction to go.
> >>>
> >>>
> >>> Best,
> >>>
> >>> Xintong
> >>>
> >>>
> >>>
> >>> On Fri, May 24, 2024 at 9:35 PM David Radley <da...@uk.ibm.com>
> >>> wrote:
> >>>
> >>>> Hi Martjin and Alex,
> >>>> I agree with your summaries, it will be interesting to see what
> >> requests
> >>>> there might be for back ports.
> >>>> Kind regards, David.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> From: Alexander Fedulov <al...@gmail.com>
> >>>> Date: Friday, 24 May 2024 at 14:07
> >>>> To: dev@flink.apache.org <de...@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 <
> martijnvisser@apache.org
> >>>
> >>>> wrote:
> >>>>
> >>>>> Hi David,
> >>>>>
> >>>>>> If there is a maintainer willing to merge backported features to
> >> v1,
> >>> as
> >>>>> it is important to some part of the community, this should be
> >> allowed,
> >>> as
> >>>>> different parts of the community have different priorities and
> >>> timelines,
> >>>>>
> >>>>> I don't think this is a good idea. Backporting a feature can cause
> >>> issues
> >>>>> in other components that might be outside the span of expertise of
> >> the
> >>>>> maintainer that backported said feature, causing the overall
> >> stability
> >>> to
> >>>>> be degraded. I think our starting point should be "We don't backport
> >>>>> features, unless discussed and agreed on the Dev mailing list". That
> >>>> still
> >>>>> opens up the ability to backport features but makes it clear where
> >> the
> >>>> bar
> >>>>> lies.
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Martijn
> >>>>>
> >>>>> On Fri, May 24, 2024 at 11:21 AM David Radley <
> >> david_radley@uk.ibm.com
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>> I agree with Martijn that we only put features into version 2. Back
> >>>>>> porting to v1 should not be business as usual for features, only
> >> for
> >>>>>> security and stability changes.
> >>>>>>
> >>>>>> If there is a maintainer willing to merge backported features to
> >> v1,
> >>> as
> >>>>> it
> >>>>>> is important to some part of the community, this should be allowed,
> >>> as
> >>>>>> different parts of the community have different priorities and
> >>>> timelines,
> >>>>>> Kind regards, David.
> >>>>>>
> >>>>>>
> >>>>>> From: Alexander Fedulov <al...@gmail.com>
> >>>>>> Date: Thursday, 23 May 2024 at 18:50
> >>>>>> To: dev@flink.apache.org <de...@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 <to...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Thanks, Alex.
> >>>>>>>
> >>>>>>> I see one task that needs to be done once the FLIP is approved,
> >>> which
> >>>>> I'd
> >>>>>>> suggest to also mention in the: To explain the LTS policy to
> >> users
> >>> on
> >>>>>>> website / documentation (because FLIP is developer-facing)
> >> before /
> >>>>> upon
> >>>>>>> releasing 1.20.
> >>>>>>>
> >>>>>>> Other than that, the FLIP LGTM.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>>
> >>>>>>> Xintong
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> >>>>>>> alexander.fedulov@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 <19...@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 <
> >>>>>>> martijnvisser@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 <
> >>> 1996fanrui@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 <
> >>>>>>>>> martijnvisser@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
> >>>>>>>>>>>> <al...@gmail.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi everyone,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> As we progress with the 1.19 release, which might
> >>>>> potentially
> >>>>>>>>>> (although
> >>>>>>>>>>>> not
> >>>>>>>>>>>>> likely) be the last in the 1.x line, I'd like to
> >> revive
> >>>> our
> >>>>>>>>>> discussion on
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> LTS support matter. There is a general consensus that
> >>> due
> >>>>> to
> >>>>>>>>>> breaking API
> >>>>>>>>>>>>> changes in 2.0, extending bug fixes support by
> >>>> designating
> >>>>> an
> >>>>>>> LTS
> >>>>>>>>>> release
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>> something we want to do.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> To summarize, the approaches we've considered are:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Time-based: The last release of the 1.x line gets a
> >>> clear
> >>>>>>>>> end-of-life
> >>>>>>>>>>>> date
> >>>>>>>>>>>>> (2 years).
> >>>>>>>>>>>>> Release-based: The last release of the 1.x line gets
> >>>>> support
> >>>>>>> for
> >>>>>>>> 4
> >>>>>>>>>> minor
> >>>>>>>>>>>>> releases in the 2.x line. The exact time is unknown,
> >>> but
> >>>> we
> >>>>>>>> assume
> >>>>>>>>>> it to
> >>>>>>>>>>>> be
> >>>>>>>>>>>>> roughly 2 years.
> >>>>>>>>>>>>> LTS-to-LTS release: The last release of the 1.x line
> >> is
> >>>>>>> supported
> >>>>>>>>>> until
> >>>>>>>>>>>> the
> >>>>>>>>>>>>> last release in the 2.x line is designated as LTS.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We need to strike a balance between being
> >> user-friendly
> >>>> and
> >>>>>>>> nudging
> >>>>>>>>>>>> people
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>> upgrade. From that perspective, option 1 is my
> >>> favorite -
> >>>>> we
> >>>>>>> all
> >>>>>>>>> know
> >>>>>>>>>>>> that
> >>>>>>>>>>>>> having a clear deadline works wonders in motivating
> >>>> action.
> >>>>>> At
> >>>>>>>> the
> >>>>>>>>>> same
> >>>>>>>>>>>>> time,
> >>>>>>>>>>>>> I appreciate that we might not want to introduce new
> >>>> kinds
> >>>>> of
> >>>>>>>>>> procedures,
> >>>>>>>>>>>>> so
> >>>>>>>>>>>>> option 2 would be my second choice, provided we also
> >>>>>> formulate
> >>>>>>> it
> >>>>>>>>>> like "4
> >>>>>>>>>>>>> minor releases, at least 2 years" (in case the minor
> >>>>> release
> >>>>>>>>> cadence
> >>>>>>>>>>>>> accelerates for some reason). I find option 3 a bit
> >>>>>> problematic
> >>>>>>>>>> since it
> >>>>>>>>>>>>> gives no incentive to upgrade, and people who do not
> >>>> follow
> >>>>>>> Flink
> >>>>>>>>>>>>> development
> >>>>>>>>>>>>> closely might be caught by surprise when we decide to
> >>>> bump
> >>>>>> the
> >>>>>>>>> major
> >>>>>>>>>>>>> version
> >>>>>>>>>>>>> again.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'd like to open a vote to stamp the official
> >> decision,
> >>>> but
> >>>>>>>> first,
> >>>>>>>>> I
> >>>>>>>>>>>> would
> >>>>>>>>>>>>> like to understand if we can reach consensus on one
> >> of
> >>>> the
> >>>>>>>> options
> >>>>>>>>>> here,
> >>>>>>>>>>>> or
> >>>>>>>>>>>>> if
> >>>>>>>>>>>>> we'll need to push that to a vote by presenting
> >>> multiple
> >>>>>>> options.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Looking forward to hearing your thoughts on this
> >>> matter.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> P.S.: 1.x and 2.x are just examples in this case; the
> >>>>>> decision
> >>>>>>>> also
> >>>>>>>>>>>>> translates
> >>>>>>>>>>>>> into a procedure for future major releases.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Best,
> >>>>>>>>>>>>> Alex
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, 27 Jul 2023 at 17:32, Jing Ge
> >>>>>>> <jing@ververica.com.invalid
> >>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Konstantin,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> What you said makes sense. Dropping modules is an
> >>>>> efficient
> >>>>>>>>> option
> >>>>>>>>>> to
> >>>>>>>>>>>>>> accelerate Flink evolution with acceptable function
> >>>>>>>> regressions.
> >>>>>>>>> We
> >>>>>>>>>>>> should
> >>>>>>>>>>>>>> do it constantly and strategically. On the other
> >>> hand,
> >>>> we
> >>>>>>>> should
> >>>>>>>>>> point
> >>>>>>>>>>>> out
> >>>>>>>>>>>>>> the core modules that must be backward compatible
> >>> when
> >>>> a
> >>>>>> new
> >>>>>>>>> major
> >>>>>>>>>>>> version
> >>>>>>>>>>>>>> is released.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>> Jing
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> >>>>>>>>>>>>>> <ma...@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.fedulov@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.pohl@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
> >>>>>>>>>>>> <ji...@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
> >>>>> <
> >>>>>>>>>>>>>> knaufk@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
> >>>>>>>>>>>>>>>>>>> <ji...@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.marton@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
> >>>>>>>> <
> >>>>>>>>>>>>>>>>> knaufk@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 <
> >>>>>>>>>>>>>>>>>>>>>> tonysong820@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 <
> >>>>>>>>>>>>>>>> xbjtdcq@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.fedulov@gmail.com>
> >>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Hello everyone,
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Recently, there were a lot of
> >>>>>>> discussions
> >>>>>>>>>> about
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> deprecation
> >>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>> various
> >>>>>>>>>>>>>>>>>>>>>>>>> APIs for the upcoming 2.0
> >>>> release.
> >>>>> It
> >>>>>>>>> appears
> >>>>>>>>>>>> there
> >>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>> two
> >>>>>>>>>>>>>>>>>>> main
> >>>>>>>>>>>>>>>>>>>>>>>> motivations
> >>>>>>>>>>>>>>>>>>>>>>>>> with opposing directions,
> >>> causing
> >>>>>> these
> >>>>>>>>>>>> discussions
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> remain
> >>>>>>>>>>>>>>>>>>>>>>> unsettled.
> >>>>>>>>>>>>>>>>>>>>>>>> On
> >>>>>>>>>>>>>>>>>>>>>>>>> one hand, there's a desire to
> >>>>> finally
> >>>>>>>> trim
> >>>>>>>>> a
> >>>>>>>>>> wide
> >>>>>>>>>>>>>> range
> >>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> legacy
> >>>>>>>>>>>>>>>>>>>>>> APIs,
> >>>>>>>>>>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>>>>> lingering around since the
> >>>>> beginning
> >>>>>> of
> >>>>>>>> the
> >>>>>>>>>> 1.x
> >>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>> line
> >>>>>>>>>>>>>>>>>>> (as
> >>>>>>>>>>>>>>>>>>>>> far
> >>>>>>>>>>>>>>>>>>>>>>>> back as
> >>>>>>>>>>>>>>>>>>>>>>>>> 2016). On the other hand,
> >> there
> >>>> is
> >>>>> a
> >>>>>>>>>> commitment
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>> uphold
> >>>>>>>>>>>>>>>>> our
> >>>>>>>>>>>>>>>>>>>>>>> guarantees
> >>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>> the users, ensuring a smooth
> >>>>>>> transition.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I believe we could reconcile
> >>>> these
> >>>>>> two
> >>>>>>>>>>>> motivations.
> >>>>>>>>>>>>>> My
> >>>>>>>>>>>>>>>>>>>> proposition
> >>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>> designate the final release
> >> of
> >>>> the
> >>>>>> 1.x
> >>>>>>>>>> timeline
> >>>>>>>>>>>> as a
> >>>>>>>>>>>>>>>>>> Long-Term
> >>>>>>>>>>>>>>>>>>>>>> Support
> >>>>>>>>>>>>>>>>>>>>>>>> (LTS)
> >>>>>>>>>>>>>>>>>>>>>>>>> release. By doing so, we
> >> would:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 1. Enable more efficient
> >>> cleanup
> >>>>> and
> >>>>>> be
> >>>>>>>>>>>> liberated to
> >>>>>>>>>>>>>>>>>> introduce
> >>>>>>>>>>>>>>>>>>>> more
> >>>>>>>>>>>>>>>>>>>>>>>> breaking
> >>>>>>>>>>>>>>>>>>>>>>>>> changes, paving the way for
> >>>>> greater
> >>>>>>>>>> innovation
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> 2.0
> >>>>>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>> 2. Sustain a positive user
> >>>>> experience
> >>>>>>> by
> >>>>>>>>>> granting
> >>>>>>>>>>>>>>> enough
> >>>>>>>>>>>>>>>>> time
> >>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>>>>>>>>> introduced in 2.0 to
> >>> stabilize,
> >>>>>>>> allowing
> >>>>>>>>>> users
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> confidently
> >>>>>>>>>>>>>>>>>>>>>>>> transition
> >>>>>>>>>>>>>>>>>>>>>>>>> their production code to
> >> the
> >>>> new
> >>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I look forward to hearing
> >> your
> >>>>>> thoughts
> >>>>>>>> on
> >>>>>>>>>> this
> >>>>>>>>>>>>>>> proposal.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>>>>>>>>>>>>>> Alex
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable
> >>>>>>>>>>>>>>>>>>>>>> https://github.com/knaufk
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable
> >>>>>>>>>>>>>>>>>>> https://github.com/knaufk
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> Unless otherwise stated above:
> >>>>>>
> >>>>>> IBM United Kingdom Limited
> >>>>>> Registered in England and Wales with number 741598
> >>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
> >>> 3AU
> >>>>>>
> >>>>>
> >>>>
> >>>> Unless otherwise stated above:
> >>>>
> >>>> IBM United Kingdom Limited
> >>>> Registered in England and Wales with number 741598
> >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
> 3AU
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Ufuk Celebi <uc...@apache.org>.
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 <al...@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 <ma...@apache.org> 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 <to...@gmail.com>
>> wrote:
>>
>>>>
>>>> I think our starting point should be "We don't backport features,
>> unless
>>>> discussed and agreed on the Dev mailing list".
>>>
>>>
>>> This makes perfect sense. In general, I think we want to encourage users
>> to
>>> upgrade in order to use the new features. Alternatively, users can also
>>> choose to maintain their own custom patches based on the LTS version. I
>>> personally don't see why backporting new features to old releases is
>>> necessary. In case of exceptions, a mailing list discussion is always a
>>> good direction to go.
>>>
>>>
>>> Best,
>>>
>>> Xintong
>>>
>>>
>>>
>>> On Fri, May 24, 2024 at 9:35 PM David Radley <da...@uk.ibm.com>
>>> wrote:
>>>
>>>> Hi Martjin and Alex,
>>>> I agree with your summaries, it will be interesting to see what
>> requests
>>>> there might be for back ports.
>>>> Kind regards, David.
>>>>
>>>>
>>>>
>>>>
>>>> From: Alexander Fedulov <al...@gmail.com>
>>>> Date: Friday, 24 May 2024 at 14:07
>>>> To: dev@flink.apache.org <de...@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 <martijnvisser@apache.org
>>>
>>>> wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>>> If there is a maintainer willing to merge backported features to
>> v1,
>>> as
>>>>> it is important to some part of the community, this should be
>> allowed,
>>> as
>>>>> different parts of the community have different priorities and
>>> timelines,
>>>>>
>>>>> I don't think this is a good idea. Backporting a feature can cause
>>> issues
>>>>> in other components that might be outside the span of expertise of
>> the
>>>>> maintainer that backported said feature, causing the overall
>> stability
>>> to
>>>>> be degraded. I think our starting point should be "We don't backport
>>>>> features, unless discussed and agreed on the Dev mailing list". That
>>>> still
>>>>> opens up the ability to backport features but makes it clear where
>> the
>>>> bar
>>>>> lies.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Martijn
>>>>>
>>>>> On Fri, May 24, 2024 at 11:21 AM David Radley <
>> david_radley@uk.ibm.com
>>>>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> I agree with Martijn that we only put features into version 2. Back
>>>>>> porting to v1 should not be business as usual for features, only
>> for
>>>>>> security and stability changes.
>>>>>>
>>>>>> If there is a maintainer willing to merge backported features to
>> v1,
>>> as
>>>>> it
>>>>>> is important to some part of the community, this should be allowed,
>>> as
>>>>>> different parts of the community have different priorities and
>>>> timelines,
>>>>>> Kind regards, David.
>>>>>>
>>>>>>
>>>>>> From: Alexander Fedulov <al...@gmail.com>
>>>>>> Date: Thursday, 23 May 2024 at 18:50
>>>>>> To: dev@flink.apache.org <de...@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 <to...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>> Thanks, Alex.
>>>>>>>
>>>>>>> I see one task that needs to be done once the FLIP is approved,
>>> which
>>>>> I'd
>>>>>>> suggest to also mention in the: To explain the LTS policy to
>> users
>>> on
>>>>>>> website / documentation (because FLIP is developer-facing)
>> before /
>>>>> upon
>>>>>>> releasing 1.20.
>>>>>>>
>>>>>>> Other than that, the FLIP LGTM.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Xintong
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
>>>>>>> alexander.fedulov@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 <19...@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 <
>>>>>>> martijnvisser@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 <
>>> 1996fanrui@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 <
>>>>>>>>> martijnvisser@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
>>>>>>>>>>>> <al...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>>
>>>>>>>>>>>>> As we progress with the 1.19 release, which might
>>>>> potentially
>>>>>>>>>> (although
>>>>>>>>>>>> not
>>>>>>>>>>>>> likely) be the last in the 1.x line, I'd like to
>> revive
>>>> our
>>>>>>>>>> discussion on
>>>>>>>>>>>>> the
>>>>>>>>>>>>> LTS support matter. There is a general consensus that
>>> due
>>>>> to
>>>>>>>>>> breaking API
>>>>>>>>>>>>> changes in 2.0, extending bug fixes support by
>>>> designating
>>>>> an
>>>>>>> LTS
>>>>>>>>>> release
>>>>>>>>>>>>> is
>>>>>>>>>>>>> something we want to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To summarize, the approaches we've considered are:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Time-based: The last release of the 1.x line gets a
>>> clear
>>>>>>>>> end-of-life
>>>>>>>>>>>> date
>>>>>>>>>>>>> (2 years).
>>>>>>>>>>>>> Release-based: The last release of the 1.x line gets
>>>>> support
>>>>>>> for
>>>>>>>> 4
>>>>>>>>>> minor
>>>>>>>>>>>>> releases in the 2.x line. The exact time is unknown,
>>> but
>>>> we
>>>>>>>> assume
>>>>>>>>>> it to
>>>>>>>>>>>> be
>>>>>>>>>>>>> roughly 2 years.
>>>>>>>>>>>>> LTS-to-LTS release: The last release of the 1.x line
>> is
>>>>>>> supported
>>>>>>>>>> until
>>>>>>>>>>>> the
>>>>>>>>>>>>> last release in the 2.x line is designated as LTS.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We need to strike a balance between being
>> user-friendly
>>>> and
>>>>>>>> nudging
>>>>>>>>>>>> people
>>>>>>>>>>>>> to
>>>>>>>>>>>>> upgrade. From that perspective, option 1 is my
>>> favorite -
>>>>> we
>>>>>>> all
>>>>>>>>> know
>>>>>>>>>>>> that
>>>>>>>>>>>>> having a clear deadline works wonders in motivating
>>>> action.
>>>>>> At
>>>>>>>> the
>>>>>>>>>> same
>>>>>>>>>>>>> time,
>>>>>>>>>>>>> I appreciate that we might not want to introduce new
>>>> kinds
>>>>> of
>>>>>>>>>> procedures,
>>>>>>>>>>>>> so
>>>>>>>>>>>>> option 2 would be my second choice, provided we also
>>>>>> formulate
>>>>>>> it
>>>>>>>>>> like "4
>>>>>>>>>>>>> minor releases, at least 2 years" (in case the minor
>>>>> release
>>>>>>>>> cadence
>>>>>>>>>>>>> accelerates for some reason). I find option 3 a bit
>>>>>> problematic
>>>>>>>>>> since it
>>>>>>>>>>>>> gives no incentive to upgrade, and people who do not
>>>> follow
>>>>>>> Flink
>>>>>>>>>>>>> development
>>>>>>>>>>>>> closely might be caught by surprise when we decide to
>>>> bump
>>>>>> the
>>>>>>>>> major
>>>>>>>>>>>>> version
>>>>>>>>>>>>> again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to open a vote to stamp the official
>> decision,
>>>> but
>>>>>>>> first,
>>>>>>>>> I
>>>>>>>>>>>> would
>>>>>>>>>>>>> like to understand if we can reach consensus on one
>> of
>>>> the
>>>>>>>> options
>>>>>>>>>> here,
>>>>>>>>>>>> or
>>>>>>>>>>>>> if
>>>>>>>>>>>>> we'll need to push that to a vote by presenting
>>> multiple
>>>>>>> options.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking forward to hearing your thoughts on this
>>> matter.
>>>>>>>>>>>>>
>>>>>>>>>>>>> P.S.: 1.x and 2.x are just examples in this case; the
>>>>>> decision
>>>>>>>> also
>>>>>>>>>>>>> translates
>>>>>>>>>>>>> into a procedure for future major releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 27 Jul 2023 at 17:32, Jing Ge
>>>>>>> <jing@ververica.com.invalid
>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Konstantin,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What you said makes sense. Dropping modules is an
>>>>> efficient
>>>>>>>>> option
>>>>>>>>>> to
>>>>>>>>>>>>>> accelerate Flink evolution with acceptable function
>>>>>>>> regressions.
>>>>>>>>> We
>>>>>>>>>>>> should
>>>>>>>>>>>>>> do it constantly and strategically. On the other
>>> hand,
>>>> we
>>>>>>>> should
>>>>>>>>>> point
>>>>>>>>>>>> out
>>>>>>>>>>>>>> the core modules that must be backward compatible
>>> when
>>>> a
>>>>>> new
>>>>>>>>> major
>>>>>>>>>>>> version
>>>>>>>>>>>>>> is released.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Jing
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
>>>>>>>>>>>>>> <ma...@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.fedulov@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.pohl@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
>>>>>>>>>>>> <ji...@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
>>>>> <
>>>>>>>>>>>>>> knaufk@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
>>>>>>>>>>>>>>>>>>> <ji...@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.marton@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
>>>>>>>> <
>>>>>>>>>>>>>>>>> knaufk@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 <
>>>>>>>>>>>>>>>>>>>>>> tonysong820@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 <
>>>>>>>>>>>>>>>> xbjtdcq@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.fedulov@gmail.com>
>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hello everyone,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Recently, there were a lot of
>>>>>>> discussions
>>>>>>>>>> about
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> deprecation
>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>> various
>>>>>>>>>>>>>>>>>>>>>>>>> APIs for the upcoming 2.0
>>>> release.
>>>>> It
>>>>>>>>> appears
>>>>>>>>>>>> there
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>>>>> main
>>>>>>>>>>>>>>>>>>>>>>>> motivations
>>>>>>>>>>>>>>>>>>>>>>>>> with opposing directions,
>>> causing
>>>>>> these
>>>>>>>>>>>> discussions
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> remain
>>>>>>>>>>>>>>>>>>>>>>> unsettled.
>>>>>>>>>>>>>>>>>>>>>>>> On
>>>>>>>>>>>>>>>>>>>>>>>>> one hand, there's a desire to
>>>>> finally
>>>>>>>> trim
>>>>>>>>> a
>>>>>>>>>> wide
>>>>>>>>>>>>>> range
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> legacy
>>>>>>>>>>>>>>>>>>>>>> APIs,
>>>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>>>> lingering around since the
>>>>> beginning
>>>>>> of
>>>>>>>> the
>>>>>>>>>> 1.x
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>>>>> (as
>>>>>>>>>>>>>>>>>>>>> far
>>>>>>>>>>>>>>>>>>>>>>>> back as
>>>>>>>>>>>>>>>>>>>>>>>>> 2016). On the other hand,
>> there
>>>> is
>>>>> a
>>>>>>>>>> commitment
>>>>>>>>>>>> to
>>>>>>>>>>>>>>> uphold
>>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>>>>>>> guarantees
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> the users, ensuring a smooth
>>>>>>> transition.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I believe we could reconcile
>>>> these
>>>>>> two
>>>>>>>>>>>> motivations.
>>>>>>>>>>>>>> My
>>>>>>>>>>>>>>>>>>>> proposition
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> designate the final release
>> of
>>>> the
>>>>>> 1.x
>>>>>>>>>> timeline
>>>>>>>>>>>> as a
>>>>>>>>>>>>>>>>>> Long-Term
>>>>>>>>>>>>>>>>>>>>>> Support
>>>>>>>>>>>>>>>>>>>>>>>> (LTS)
>>>>>>>>>>>>>>>>>>>>>>>>> release. By doing so, we
>> would:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 1. Enable more efficient
>>> cleanup
>>>>> and
>>>>>> be
>>>>>>>>>>>> liberated to
>>>>>>>>>>>>>>>>>> introduce
>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>>>>> breaking
>>>>>>>>>>>>>>>>>>>>>>>>> changes, paving the way for
>>>>> greater
>>>>>>>>>> innovation
>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> 2.0
>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>> 2. Sustain a positive user
>>>>> experience
>>>>>>> by
>>>>>>>>>> granting
>>>>>>>>>>>>>>> enough
>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>>>>>>>>>> introduced in 2.0 to
>>> stabilize,
>>>>>>>> allowing
>>>>>>>>>> users
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> confidently
>>>>>>>>>>>>>>>>>>>>>>>> transition
>>>>>>>>>>>>>>>>>>>>>>>>> their production code to
>> the
>>>> new
>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I look forward to hearing
>> your
>>>>>> thoughts
>>>>>>>> on
>>>>>>>>>> this
>>>>>>>>>>>>>>> proposal.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable
>>>>>>>>>>>>>>>>>>>>>> https://github.com/knaufk
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable
>>>>>>>>>>>>>>>>>>> https://github.com/knaufk
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Unless otherwise stated above:
>>>>>>
>>>>>> IBM United Kingdom Limited
>>>>>> Registered in England and Wales with number 741598
>>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
>>> 3AU
>>>>>>
>>>>>
>>>>
>>>> Unless otherwise stated above:
>>>>
>>>> IBM United Kingdom Limited
>>>> Registered in England and Wales with number 741598
>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>>>>
>>>
>>
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Alexander Fedulov <al...@gmail.com>.
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 <ma...@apache.org> 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 <to...@gmail.com>
> wrote:
>
> > >
> > > I think our starting point should be "We don't backport features,
> unless
> > > discussed and agreed on the Dev mailing list".
> >
> >
> > This makes perfect sense. In general, I think we want to encourage users
> to
> > upgrade in order to use the new features. Alternatively, users can also
> > choose to maintain their own custom patches based on the LTS version. I
> > personally don't see why backporting new features to old releases is
> > necessary. In case of exceptions, a mailing list discussion is always a
> > good direction to go.
> >
> >
> > Best,
> >
> > Xintong
> >
> >
> >
> > On Fri, May 24, 2024 at 9:35 PM David Radley <da...@uk.ibm.com>
> > wrote:
> >
> > > Hi Martjin and Alex,
> > > I agree with your summaries, it will be interesting to see what
> requests
> > > there might be for back ports.
> > > Kind regards, David.
> > >
> > >
> > >
> > >
> > > From: Alexander Fedulov <al...@gmail.com>
> > > Date: Friday, 24 May 2024 at 14:07
> > > To: dev@flink.apache.org <de...@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 <martijnvisser@apache.org
> >
> > > wrote:
> > >
> > > > Hi David,
> > > >
> > > > > If there is a maintainer willing to merge backported features to
> v1,
> > as
> > > > it is important to some part of the community, this should be
> allowed,
> > as
> > > > different parts of the community have different priorities and
> > timelines,
> > > >
> > > > I don't think this is a good idea. Backporting a feature can cause
> > issues
> > > > in other components that might be outside the span of expertise of
> the
> > > > maintainer that backported said feature, causing the overall
> stability
> > to
> > > > be degraded. I think our starting point should be "We don't backport
> > > > features, unless discussed and agreed on the Dev mailing list". That
> > > still
> > > > opens up the ability to backport features but makes it clear where
> the
> > > bar
> > > > lies.
> > > >
> > > > Best regards,
> > > >
> > > > Martijn
> > > >
> > > > On Fri, May 24, 2024 at 11:21 AM David Radley <
> david_radley@uk.ibm.com
> > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > > I agree with Martijn that we only put features into version 2. Back
> > > > > porting to v1 should not be business as usual for features, only
> for
> > > > > security and stability changes.
> > > > >
> > > > > If there is a maintainer willing to merge backported features to
> v1,
> > as
> > > > it
> > > > > is important to some part of the community, this should be allowed,
> > as
> > > > > different parts of the community have different priorities and
> > > timelines,
> > > > > Kind regards, David.
> > > > >
> > > > >
> > > > > From: Alexander Fedulov <al...@gmail.com>
> > > > > Date: Thursday, 23 May 2024 at 18:50
> > > > > To: dev@flink.apache.org <de...@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 <to...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Thanks, Alex.
> > > > > >
> > > > > > I see one task that needs to be done once the FLIP is approved,
> > which
> > > > I'd
> > > > > > suggest to also mention in the: To explain the LTS policy to
> users
> > on
> > > > > > website / documentation (because FLIP is developer-facing)
> before /
> > > > upon
> > > > > > releasing 1.20.
> > > > > >
> > > > > > Other than that, the FLIP LGTM.
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > > Xintong
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> > > > > > alexander.fedulov@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 <19...@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 <
> > > > > > martijnvisser@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 <
> > 1996fanrui@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 <
> > > > > > > > martijnvisser@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
> > > > > > > > > > > <al...@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi everyone,
> > > > > > > > > > > >
> > > > > > > > > > > > As we progress with the 1.19 release, which might
> > > > potentially
> > > > > > > > > (although
> > > > > > > > > > > not
> > > > > > > > > > > > likely) be the last in the 1.x line, I'd like to
> revive
> > > our
> > > > > > > > > discussion on
> > > > > > > > > > > > the
> > > > > > > > > > > > LTS support matter. There is a general consensus that
> > due
> > > > to
> > > > > > > > > breaking API
> > > > > > > > > > > > changes in 2.0, extending bug fixes support by
> > > designating
> > > > an
> > > > > > LTS
> > > > > > > > > release
> > > > > > > > > > > > is
> > > > > > > > > > > > something we want to do.
> > > > > > > > > > > >
> > > > > > > > > > > > To summarize, the approaches we've considered are:
> > > > > > > > > > > >
> > > > > > > > > > > > Time-based: The last release of the 1.x line gets a
> > clear
> > > > > > > > end-of-life
> > > > > > > > > > > date
> > > > > > > > > > > > (2 years).
> > > > > > > > > > > > Release-based: The last release of the 1.x line gets
> > > > support
> > > > > > for
> > > > > > > 4
> > > > > > > > > minor
> > > > > > > > > > > > releases in the 2.x line. The exact time is unknown,
> > but
> > > we
> > > > > > > assume
> > > > > > > > > it to
> > > > > > > > > > > be
> > > > > > > > > > > > roughly 2 years.
> > > > > > > > > > > > LTS-to-LTS release: The last release of the 1.x line
> is
> > > > > > supported
> > > > > > > > > until
> > > > > > > > > > > the
> > > > > > > > > > > > last release in the 2.x line is designated as LTS.
> > > > > > > > > > > >
> > > > > > > > > > > > We need to strike a balance between being
> user-friendly
> > > and
> > > > > > > nudging
> > > > > > > > > > > people
> > > > > > > > > > > > to
> > > > > > > > > > > > upgrade. From that perspective, option 1 is my
> > favorite -
> > > > we
> > > > > > all
> > > > > > > > know
> > > > > > > > > > > that
> > > > > > > > > > > > having a clear deadline works wonders in motivating
> > > action.
> > > > > At
> > > > > > > the
> > > > > > > > > same
> > > > > > > > > > > > time,
> > > > > > > > > > > > I appreciate that we might not want to introduce new
> > > kinds
> > > > of
> > > > > > > > > procedures,
> > > > > > > > > > > > so
> > > > > > > > > > > > option 2 would be my second choice, provided we also
> > > > > formulate
> > > > > > it
> > > > > > > > > like "4
> > > > > > > > > > > > minor releases, at least 2 years" (in case the minor
> > > > release
> > > > > > > > cadence
> > > > > > > > > > > > accelerates for some reason). I find option 3 a bit
> > > > > problematic
> > > > > > > > > since it
> > > > > > > > > > > > gives no incentive to upgrade, and people who do not
> > > follow
> > > > > > Flink
> > > > > > > > > > > > development
> > > > > > > > > > > > closely might be caught by surprise when we decide to
> > > bump
> > > > > the
> > > > > > > > major
> > > > > > > > > > > > version
> > > > > > > > > > > > again.
> > > > > > > > > > > >
> > > > > > > > > > > > I'd like to open a vote to stamp the official
> decision,
> > > but
> > > > > > > first,
> > > > > > > > I
> > > > > > > > > > > would
> > > > > > > > > > > > like to understand if we can reach consensus on one
> of
> > > the
> > > > > > > options
> > > > > > > > > here,
> > > > > > > > > > > or
> > > > > > > > > > > > if
> > > > > > > > > > > > we'll need to push that to a vote by presenting
> > multiple
> > > > > > options.
> > > > > > > > > > > >
> > > > > > > > > > > > Looking forward to hearing your thoughts on this
> > matter.
> > > > > > > > > > > >
> > > > > > > > > > > > P.S.: 1.x and 2.x are just examples in this case; the
> > > > > decision
> > > > > > > also
> > > > > > > > > > > > translates
> > > > > > > > > > > > into a procedure for future major releases.
> > > > > > > > > > > >
> > > > > > > > > > > > Best,
> > > > > > > > > > > > Alex
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge
> > > > > > <jing@ververica.com.invalid
> > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Konstantin,
> > > > > > > > > > > > >
> > > > > > > > > > > > > What you said makes sense. Dropping modules is an
> > > > efficient
> > > > > > > > option
> > > > > > > > > to
> > > > > > > > > > > > > accelerate Flink evolution with acceptable function
> > > > > > > regressions.
> > > > > > > > We
> > > > > > > > > > > should
> > > > > > > > > > > > > do it constantly and strategically. On the other
> > hand,
> > > we
> > > > > > > should
> > > > > > > > > point
> > > > > > > > > > > out
> > > > > > > > > > > > > the core modules that must be backward compatible
> > when
> > > a
> > > > > new
> > > > > > > > major
> > > > > > > > > > > version
> > > > > > > > > > > > > is released.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Best regards,
> > > > > > > > > > > > > Jing
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > > > > > > > <ji...@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
> > > > <
> > > > > > > > > > > > > knaufk@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
> > > > > > > > > > > > > > > > > > <ji...@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.marton@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
> > > > > > > <
> > > > > > > > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > > > > > > > xbjtdcq@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.fedulov@gmail.com>
> > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Recently, there were a lot of
> > > > > > discussions
> > > > > > > > > about
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > > deprecation
> > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > > > APIs for the upcoming 2.0
> > > release.
> > > > It
> > > > > > > > appears
> > > > > > > > > > > there
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > two
> > > > > > > > > > > > > > > > > > main
> > > > > > > > > > > > > > > > > > > > > > > motivations
> > > > > > > > > > > > > > > > > > > > > > > > with opposing directions,
> > causing
> > > > > these
> > > > > > > > > > > discussions
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > remain
> > > > > > > > > > > > > > > > > > > > > > unsettled.
> > > > > > > > > > > > > > > > > > > > > > > On
> > > > > > > > > > > > > > > > > > > > > > > > one hand, there's a desire to
> > > > finally
> > > > > > > trim
> > > > > > > > a
> > > > > > > > > wide
> > > > > > > > > > > > > range
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > legacy
> > > > > > > > > > > > > > > > > > > > > APIs,
> > > > > > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > > > > lingering around since the
> > > > beginning
> > > > > of
> > > > > > > the
> > > > > > > > > 1.x
> > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > line
> > > > > > > > > > > > > > > > > > (as
> > > > > > > > > > > > > > > > > > > > far
> > > > > > > > > > > > > > > > > > > > > > > back as
> > > > > > > > > > > > > > > > > > > > > > > > 2016). On the other hand,
> there
> > > is
> > > > a
> > > > > > > > > commitment
> > > > > > > > > > > to
> > > > > > > > > > > > > > uphold
> > > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > > > guarantees
> > > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > the users, ensuring a smooth
> > > > > > transition.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I believe we could reconcile
> > > these
> > > > > two
> > > > > > > > > > > motivations.
> > > > > > > > > > > > > My
> > > > > > > > > > > > > > > > > > > proposition
> > > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > designate the final release
> of
> > > the
> > > > > 1.x
> > > > > > > > > timeline
> > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > Long-Term
> > > > > > > > > > > > > > > > > > > > > Support
> > > > > > > > > > > > > > > > > > > > > > > (LTS)
> > > > > > > > > > > > > > > > > > > > > > > > release. By doing so, we
> would:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 1. Enable more efficient
> > cleanup
> > > > and
> > > > > be
> > > > > > > > > > > liberated to
> > > > > > > > > > > > > > > > > introduce
> > > > > > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > > > > > > > > changes, paving the way for
> > > > greater
> > > > > > > > > innovation
> > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > 2.0
> > > > > > > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > > > > > > > > 2. Sustain a positive user
> > > > experience
> > > > > > by
> > > > > > > > > granting
> > > > > > > > > > > > > > enough
> > > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > > > > > > introduced in 2.0 to
> > stabilize,
> > > > > > > allowing
> > > > > > > > > users
> > > > > > > > > > > to
> > > > > > > > > > > > > > > > > confidently
> > > > > > > > > > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > > > > > > > > > > their production code to
> the
> > > new
> > > > > > > release.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I look forward to hearing
> your
> > > > > thoughts
> > > > > > > on
> > > > > > > > > this
> > > > > > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Best Regards,
> > > > > > > > > > > > > > > > > > > > > > > > Alex
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > Unless otherwise stated above:
> > > > >
> > > > > IBM United Kingdom Limited
> > > > > Registered in England and Wales with number 741598
> > > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
> > 3AU
> > > > >
> > > >
> > >
> > > Unless otherwise stated above:
> > >
> > > IBM United Kingdom Limited
> > > Registered in England and Wales with number 741598
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> > >
> >
>
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Matthias Pohl <ma...@apache.org>.
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 <to...@gmail.com> wrote:
> >
> > I think our starting point should be "We don't backport features, unless
> > discussed and agreed on the Dev mailing list".
>
>
> This makes perfect sense. In general, I think we want to encourage users to
> upgrade in order to use the new features. Alternatively, users can also
> choose to maintain their own custom patches based on the LTS version. I
> personally don't see why backporting new features to old releases is
> necessary. In case of exceptions, a mailing list discussion is always a
> good direction to go.
>
>
> Best,
>
> Xintong
>
>
>
> On Fri, May 24, 2024 at 9:35 PM David Radley <da...@uk.ibm.com>
> wrote:
>
> > Hi Martjin and Alex,
> > I agree with your summaries, it will be interesting to see what requests
> > there might be for back ports.
> > Kind regards, David.
> >
> >
> >
> >
> > From: Alexander Fedulov <al...@gmail.com>
> > Date: Friday, 24 May 2024 at 14:07
> > To: dev@flink.apache.org <de...@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 <ma...@apache.org>
> > wrote:
> >
> > > Hi David,
> > >
> > > > If there is a maintainer willing to merge backported features to v1,
> as
> > > it is important to some part of the community, this should be allowed,
> as
> > > different parts of the community have different priorities and
> timelines,
> > >
> > > I don't think this is a good idea. Backporting a feature can cause
> issues
> > > in other components that might be outside the span of expertise of the
> > > maintainer that backported said feature, causing the overall stability
> to
> > > be degraded. I think our starting point should be "We don't backport
> > > features, unless discussed and agreed on the Dev mailing list". That
> > still
> > > opens up the ability to backport features but makes it clear where the
> > bar
> > > lies.
> > >
> > > Best regards,
> > >
> > > Martijn
> > >
> > > On Fri, May 24, 2024 at 11:21 AM David Radley <david_radley@uk.ibm.com
> >
> > > wrote:
> > >
> > > > Hi,
> > > > I agree with Martijn that we only put features into version 2. Back
> > > > porting to v1 should not be business as usual for features, only for
> > > > security and stability changes.
> > > >
> > > > If there is a maintainer willing to merge backported features to v1,
> as
> > > it
> > > > is important to some part of the community, this should be allowed,
> as
> > > > different parts of the community have different priorities and
> > timelines,
> > > > Kind regards, David.
> > > >
> > > >
> > > > From: Alexander Fedulov <al...@gmail.com>
> > > > Date: Thursday, 23 May 2024 at 18:50
> > > > To: dev@flink.apache.org <de...@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 <to...@gmail.com>
> > > wrote:
> > > >
> > > > > Thanks, Alex.
> > > > >
> > > > > I see one task that needs to be done once the FLIP is approved,
> which
> > > I'd
> > > > > suggest to also mention in the: To explain the LTS policy to users
> on
> > > > > website / documentation (because FLIP is developer-facing) before /
> > > upon
> > > > > releasing 1.20.
> > > > >
> > > > > Other than that, the FLIP LGTM.
> > > > >
> > > > > Best,
> > > > >
> > > > > Xintong
> > > > >
> > > > >
> > > > >
> > > > > On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> > > > > alexander.fedulov@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 <19...@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 <
> > > > > martijnvisser@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 <
> 1996fanrui@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 <
> > > > > > > martijnvisser@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
> > > > > > > > > > <al...@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi everyone,
> > > > > > > > > > >
> > > > > > > > > > > As we progress with the 1.19 release, which might
> > > potentially
> > > > > > > > (although
> > > > > > > > > > not
> > > > > > > > > > > likely) be the last in the 1.x line, I'd like to revive
> > our
> > > > > > > > discussion on
> > > > > > > > > > > the
> > > > > > > > > > > LTS support matter. There is a general consensus that
> due
> > > to
> > > > > > > > breaking API
> > > > > > > > > > > changes in 2.0, extending bug fixes support by
> > designating
> > > an
> > > > > LTS
> > > > > > > > release
> > > > > > > > > > > is
> > > > > > > > > > > something we want to do.
> > > > > > > > > > >
> > > > > > > > > > > To summarize, the approaches we've considered are:
> > > > > > > > > > >
> > > > > > > > > > > Time-based: The last release of the 1.x line gets a
> clear
> > > > > > > end-of-life
> > > > > > > > > > date
> > > > > > > > > > > (2 years).
> > > > > > > > > > > Release-based: The last release of the 1.x line gets
> > > support
> > > > > for
> > > > > > 4
> > > > > > > > minor
> > > > > > > > > > > releases in the 2.x line. The exact time is unknown,
> but
> > we
> > > > > > assume
> > > > > > > > it to
> > > > > > > > > > be
> > > > > > > > > > > roughly 2 years.
> > > > > > > > > > > LTS-to-LTS release: The last release of the 1.x line is
> > > > > supported
> > > > > > > > until
> > > > > > > > > > the
> > > > > > > > > > > last release in the 2.x line is designated as LTS.
> > > > > > > > > > >
> > > > > > > > > > > We need to strike a balance between being user-friendly
> > and
> > > > > > nudging
> > > > > > > > > > people
> > > > > > > > > > > to
> > > > > > > > > > > upgrade. From that perspective, option 1 is my
> favorite -
> > > we
> > > > > all
> > > > > > > know
> > > > > > > > > > that
> > > > > > > > > > > having a clear deadline works wonders in motivating
> > action.
> > > > At
> > > > > > the
> > > > > > > > same
> > > > > > > > > > > time,
> > > > > > > > > > > I appreciate that we might not want to introduce new
> > kinds
> > > of
> > > > > > > > procedures,
> > > > > > > > > > > so
> > > > > > > > > > > option 2 would be my second choice, provided we also
> > > > formulate
> > > > > it
> > > > > > > > like "4
> > > > > > > > > > > minor releases, at least 2 years" (in case the minor
> > > release
> > > > > > > cadence
> > > > > > > > > > > accelerates for some reason). I find option 3 a bit
> > > > problematic
> > > > > > > > since it
> > > > > > > > > > > gives no incentive to upgrade, and people who do not
> > follow
> > > > > Flink
> > > > > > > > > > > development
> > > > > > > > > > > closely might be caught by surprise when we decide to
> > bump
> > > > the
> > > > > > > major
> > > > > > > > > > > version
> > > > > > > > > > > again.
> > > > > > > > > > >
> > > > > > > > > > > I'd like to open a vote to stamp the official decision,
> > but
> > > > > > first,
> > > > > > > I
> > > > > > > > > > would
> > > > > > > > > > > like to understand if we can reach consensus on one of
> > the
> > > > > > options
> > > > > > > > here,
> > > > > > > > > > or
> > > > > > > > > > > if
> > > > > > > > > > > we'll need to push that to a vote by presenting
> multiple
> > > > > options.
> > > > > > > > > > >
> > > > > > > > > > > Looking forward to hearing your thoughts on this
> matter.
> > > > > > > > > > >
> > > > > > > > > > > P.S.: 1.x and 2.x are just examples in this case; the
> > > > decision
> > > > > > also
> > > > > > > > > > > translates
> > > > > > > > > > > into a procedure for future major releases.
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > Alex
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge
> > > > > <jing@ververica.com.invalid
> > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Konstantin,
> > > > > > > > > > > >
> > > > > > > > > > > > What you said makes sense. Dropping modules is an
> > > efficient
> > > > > > > option
> > > > > > > > to
> > > > > > > > > > > > accelerate Flink evolution with acceptable function
> > > > > > regressions.
> > > > > > > We
> > > > > > > > > > should
> > > > > > > > > > > > do it constantly and strategically. On the other
> hand,
> > we
> > > > > > should
> > > > > > > > point
> > > > > > > > > > out
> > > > > > > > > > > > the core modules that must be backward compatible
> when
> > a
> > > > new
> > > > > > > major
> > > > > > > > > > version
> > > > > > > > > > > > is released.
> > > > > > > > > > > >
> > > > > > > > > > > > Best regards,
> > > > > > > > > > > > Jing
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > > > > > > <ji...@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
> > > <
> > > > > > > > > > > > knaufk@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
> > > > > > > > > > > > > > > > > <ji...@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.marton@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
> > > > > > <
> > > > > > > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > > > > > > xbjtdcq@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.fedulov@gmail.com>
> > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Recently, there were a lot of
> > > > > discussions
> > > > > > > > about
> > > > > > > > > > the
> > > > > > > > > > > > > > > > deprecation
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > > APIs for the upcoming 2.0
> > release.
> > > It
> > > > > > > appears
> > > > > > > > > > there
> > > > > > > > > > > > are
> > > > > > > > > > > > > > two
> > > > > > > > > > > > > > > > > main
> > > > > > > > > > > > > > > > > > > > > > motivations
> > > > > > > > > > > > > > > > > > > > > > > with opposing directions,
> causing
> > > > these
> > > > > > > > > > discussions
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > remain
> > > > > > > > > > > > > > > > > > > > > unsettled.
> > > > > > > > > > > > > > > > > > > > > > On
> > > > > > > > > > > > > > > > > > > > > > > one hand, there's a desire to
> > > finally
> > > > > > trim
> > > > > > > a
> > > > > > > > wide
> > > > > > > > > > > > range
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > legacy
> > > > > > > > > > > > > > > > > > > > APIs,
> > > > > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > > > lingering around since the
> > > beginning
> > > > of
> > > > > > the
> > > > > > > > 1.x
> > > > > > > > > > > > release
> > > > > > > > > > > > > > > line
> > > > > > > > > > > > > > > > > (as
> > > > > > > > > > > > > > > > > > > far
> > > > > > > > > > > > > > > > > > > > > > back as
> > > > > > > > > > > > > > > > > > > > > > > 2016). On the other hand, there
> > is
> > > a
> > > > > > > > commitment
> > > > > > > > > > to
> > > > > > > > > > > > > uphold
> > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > > guarantees
> > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > the users, ensuring a smooth
> > > > > transition.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I believe we could reconcile
> > these
> > > > two
> > > > > > > > > > motivations.
> > > > > > > > > > > > My
> > > > > > > > > > > > > > > > > > proposition
> > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > designate the final release of
> > the
> > > > 1.x
> > > > > > > > timeline
> > > > > > > > > > as a
> > > > > > > > > > > > > > > > Long-Term
> > > > > > > > > > > > > > > > > > > > Support
> > > > > > > > > > > > > > > > > > > > > > (LTS)
> > > > > > > > > > > > > > > > > > > > > > > release. By doing so, we would:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 1. Enable more efficient
> cleanup
> > > and
> > > > be
> > > > > > > > > > liberated to
> > > > > > > > > > > > > > > > introduce
> > > > > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > > > > > > > changes, paving the way for
> > > greater
> > > > > > > > innovation
> > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > > > 2.0
> > > > > > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > > > > > > > 2. Sustain a positive user
> > > experience
> > > > > by
> > > > > > > > granting
> > > > > > > > > > > > > enough
> > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > > > > > introduced in 2.0 to
> stabilize,
> > > > > > allowing
> > > > > > > > users
> > > > > > > > > > to
> > > > > > > > > > > > > > > > confidently
> > > > > > > > > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > > > > > > > > > their production code to the
> > new
> > > > > > release.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I look forward to hearing your
> > > > thoughts
> > > > > > on
> > > > > > > > this
> > > > > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Best Regards,
> > > > > > > > > > > > > > > > > > > > > > > Alex
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > Unless otherwise stated above:
> > > >
> > > > IBM United Kingdom Limited
> > > > Registered in England and Wales with number 741598
> > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
> 3AU
> > > >
> > >
> >
> > Unless otherwise stated above:
> >
> > IBM United Kingdom Limited
> > Registered in England and Wales with number 741598
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> >
>
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Xintong Song <to...@gmail.com>.
>
> 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 <da...@uk.ibm.com>
wrote:
> Hi Martjin and Alex,
> I agree with your summaries, it will be interesting to see what requests
> there might be for back ports.
> Kind regards, David.
>
>
>
>
> From: Alexander Fedulov <al...@gmail.com>
> Date: Friday, 24 May 2024 at 14:07
> To: dev@flink.apache.org <de...@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 <ma...@apache.org>
> wrote:
>
> > Hi David,
> >
> > > If there is a maintainer willing to merge backported features to v1, as
> > it is important to some part of the community, this should be allowed, as
> > different parts of the community have different priorities and timelines,
> >
> > I don't think this is a good idea. Backporting a feature can cause issues
> > in other components that might be outside the span of expertise of the
> > maintainer that backported said feature, causing the overall stability to
> > be degraded. I think our starting point should be "We don't backport
> > features, unless discussed and agreed on the Dev mailing list". That
> still
> > opens up the ability to backport features but makes it clear where the
> bar
> > lies.
> >
> > Best regards,
> >
> > Martijn
> >
> > On Fri, May 24, 2024 at 11:21 AM David Radley <da...@uk.ibm.com>
> > wrote:
> >
> > > Hi,
> > > I agree with Martijn that we only put features into version 2. Back
> > > porting to v1 should not be business as usual for features, only for
> > > security and stability changes.
> > >
> > > If there is a maintainer willing to merge backported features to v1, as
> > it
> > > is important to some part of the community, this should be allowed, as
> > > different parts of the community have different priorities and
> timelines,
> > > Kind regards, David.
> > >
> > >
> > > From: Alexander Fedulov <al...@gmail.com>
> > > Date: Thursday, 23 May 2024 at 18:50
> > > To: dev@flink.apache.org <de...@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 <to...@gmail.com>
> > wrote:
> > >
> > > > Thanks, Alex.
> > > >
> > > > I see one task that needs to be done once the FLIP is approved, which
> > I'd
> > > > suggest to also mention in the: To explain the LTS policy to users on
> > > > website / documentation (because FLIP is developer-facing) before /
> > upon
> > > > releasing 1.20.
> > > >
> > > > Other than that, the FLIP LGTM.
> > > >
> > > > Best,
> > > >
> > > > Xintong
> > > >
> > > >
> > > >
> > > > On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> > > > alexander.fedulov@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 <19...@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 <
> > > > martijnvisser@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 <19...@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 <
> > > > > > martijnvisser@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
> > > > > > > > > <al...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi everyone,
> > > > > > > > > >
> > > > > > > > > > As we progress with the 1.19 release, which might
> > potentially
> > > > > > > (although
> > > > > > > > > not
> > > > > > > > > > likely) be the last in the 1.x line, I'd like to revive
> our
> > > > > > > discussion on
> > > > > > > > > > the
> > > > > > > > > > LTS support matter. There is a general consensus that due
> > to
> > > > > > > breaking API
> > > > > > > > > > changes in 2.0, extending bug fixes support by
> designating
> > an
> > > > LTS
> > > > > > > release
> > > > > > > > > > is
> > > > > > > > > > something we want to do.
> > > > > > > > > >
> > > > > > > > > > To summarize, the approaches we've considered are:
> > > > > > > > > >
> > > > > > > > > > Time-based: The last release of the 1.x line gets a clear
> > > > > > end-of-life
> > > > > > > > > date
> > > > > > > > > > (2 years).
> > > > > > > > > > Release-based: The last release of the 1.x line gets
> > support
> > > > for
> > > > > 4
> > > > > > > minor
> > > > > > > > > > releases in the 2.x line. The exact time is unknown, but
> we
> > > > > assume
> > > > > > > it to
> > > > > > > > > be
> > > > > > > > > > roughly 2 years.
> > > > > > > > > > LTS-to-LTS release: The last release of the 1.x line is
> > > > supported
> > > > > > > until
> > > > > > > > > the
> > > > > > > > > > last release in the 2.x line is designated as LTS.
> > > > > > > > > >
> > > > > > > > > > We need to strike a balance between being user-friendly
> and
> > > > > nudging
> > > > > > > > > people
> > > > > > > > > > to
> > > > > > > > > > upgrade. From that perspective, option 1 is my favorite -
> > we
> > > > all
> > > > > > know
> > > > > > > > > that
> > > > > > > > > > having a clear deadline works wonders in motivating
> action.
> > > At
> > > > > the
> > > > > > > same
> > > > > > > > > > time,
> > > > > > > > > > I appreciate that we might not want to introduce new
> kinds
> > of
> > > > > > > procedures,
> > > > > > > > > > so
> > > > > > > > > > option 2 would be my second choice, provided we also
> > > formulate
> > > > it
> > > > > > > like "4
> > > > > > > > > > minor releases, at least 2 years" (in case the minor
> > release
> > > > > > cadence
> > > > > > > > > > accelerates for some reason). I find option 3 a bit
> > > problematic
> > > > > > > since it
> > > > > > > > > > gives no incentive to upgrade, and people who do not
> follow
> > > > Flink
> > > > > > > > > > development
> > > > > > > > > > closely might be caught by surprise when we decide to
> bump
> > > the
> > > > > > major
> > > > > > > > > > version
> > > > > > > > > > again.
> > > > > > > > > >
> > > > > > > > > > I'd like to open a vote to stamp the official decision,
> but
> > > > > first,
> > > > > > I
> > > > > > > > > would
> > > > > > > > > > like to understand if we can reach consensus on one of
> the
> > > > > options
> > > > > > > here,
> > > > > > > > > or
> > > > > > > > > > if
> > > > > > > > > > we'll need to push that to a vote by presenting multiple
> > > > options.
> > > > > > > > > >
> > > > > > > > > > Looking forward to hearing your thoughts on this matter.
> > > > > > > > > >
> > > > > > > > > > P.S.: 1.x and 2.x are just examples in this case; the
> > > decision
> > > > > also
> > > > > > > > > > translates
> > > > > > > > > > into a procedure for future major releases.
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > Alex
> > > > > > > > > >
> > > > > > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge
> > > > <jing@ververica.com.invalid
> > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Konstantin,
> > > > > > > > > > >
> > > > > > > > > > > What you said makes sense. Dropping modules is an
> > efficient
> > > > > > option
> > > > > > > to
> > > > > > > > > > > accelerate Flink evolution with acceptable function
> > > > > regressions.
> > > > > > We
> > > > > > > > > should
> > > > > > > > > > > do it constantly and strategically. On the other hand,
> we
> > > > > should
> > > > > > > point
> > > > > > > > > out
> > > > > > > > > > > the core modules that must be backward compatible when
> a
> > > new
> > > > > > major
> > > > > > > > > version
> > > > > > > > > > > is released.
> > > > > > > > > > >
> > > > > > > > > > > Best regards,
> > > > > > > > > > > Jing
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > > > > > <ji...@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
> > <
> > > > > > > > > > > knaufk@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
> > > > > > > > > > > > > > > > <ji...@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.marton@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
> > > > > <
> > > > > > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > > > > > xbjtdcq@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.fedulov@gmail.com>
> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Recently, there were a lot of
> > > > discussions
> > > > > > > about
> > > > > > > > > the
> > > > > > > > > > > > > > > deprecation
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > APIs for the upcoming 2.0
> release.
> > It
> > > > > > appears
> > > > > > > > > there
> > > > > > > > > > > are
> > > > > > > > > > > > > two
> > > > > > > > > > > > > > > > main
> > > > > > > > > > > > > > > > > > > > > motivations
> > > > > > > > > > > > > > > > > > > > > > with opposing directions, causing
> > > these
> > > > > > > > > discussions
> > > > > > > > > > > to
> > > > > > > > > > > > > > remain
> > > > > > > > > > > > > > > > > > > > unsettled.
> > > > > > > > > > > > > > > > > > > > > On
> > > > > > > > > > > > > > > > > > > > > > one hand, there's a desire to
> > finally
> > > > > trim
> > > > > > a
> > > > > > > wide
> > > > > > > > > > > range
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > legacy
> > > > > > > > > > > > > > > > > > > APIs,
> > > > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > > lingering around since the
> > beginning
> > > of
> > > > > the
> > > > > > > 1.x
> > > > > > > > > > > release
> > > > > > > > > > > > > > line
> > > > > > > > > > > > > > > > (as
> > > > > > > > > > > > > > > > > > far
> > > > > > > > > > > > > > > > > > > > > back as
> > > > > > > > > > > > > > > > > > > > > > 2016). On the other hand, there
> is
> > a
> > > > > > > commitment
> > > > > > > > > to
> > > > > > > > > > > > uphold
> > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > guarantees
> > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > the users, ensuring a smooth
> > > > transition.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I believe we could reconcile
> these
> > > two
> > > > > > > > > motivations.
> > > > > > > > > > > My
> > > > > > > > > > > > > > > > > proposition
> > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > designate the final release of
> the
> > > 1.x
> > > > > > > timeline
> > > > > > > > > as a
> > > > > > > > > > > > > > > Long-Term
> > > > > > > > > > > > > > > > > > > Support
> > > > > > > > > > > > > > > > > > > > > (LTS)
> > > > > > > > > > > > > > > > > > > > > > release. By doing so, we would:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 1. Enable more efficient cleanup
> > and
> > > be
> > > > > > > > > liberated to
> > > > > > > > > > > > > > > introduce
> > > > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > > > > > > changes, paving the way for
> > greater
> > > > > > > innovation
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > > > 2.0
> > > > > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > > > > > > 2. Sustain a positive user
> > experience
> > > > by
> > > > > > > granting
> > > > > > > > > > > > enough
> > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > > > > introduced in 2.0 to stabilize,
> > > > > allowing
> > > > > > > users
> > > > > > > > > to
> > > > > > > > > > > > > > > confidently
> > > > > > > > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > > > > > > > > their production code to the
> new
> > > > > release.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I look forward to hearing your
> > > thoughts
> > > > > on
> > > > > > > this
> > > > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Best Regards,
> > > > > > > > > > > > > > > > > > > > > > Alex
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > > Unless otherwise stated above:
> > >
> > > IBM United Kingdom Limited
> > > Registered in England and Wales with number 741598
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> > >
> >
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
RE: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by David Radley <da...@uk.ibm.com>.
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 <al...@gmail.com>
Date: Friday, 24 May 2024 at 14:07
To: dev@flink.apache.org <de...@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 <ma...@apache.org>
wrote:
> Hi David,
>
> > If there is a maintainer willing to merge backported features to v1, as
> it is important to some part of the community, this should be allowed, as
> different parts of the community have different priorities and timelines,
>
> I don't think this is a good idea. Backporting a feature can cause issues
> in other components that might be outside the span of expertise of the
> maintainer that backported said feature, causing the overall stability to
> be degraded. I think our starting point should be "We don't backport
> features, unless discussed and agreed on the Dev mailing list". That still
> opens up the ability to backport features but makes it clear where the bar
> lies.
>
> Best regards,
>
> Martijn
>
> On Fri, May 24, 2024 at 11:21 AM David Radley <da...@uk.ibm.com>
> wrote:
>
> > Hi,
> > I agree with Martijn that we only put features into version 2. Back
> > porting to v1 should not be business as usual for features, only for
> > security and stability changes.
> >
> > If there is a maintainer willing to merge backported features to v1, as
> it
> > is important to some part of the community, this should be allowed, as
> > different parts of the community have different priorities and timelines,
> > Kind regards, David.
> >
> >
> > From: Alexander Fedulov <al...@gmail.com>
> > Date: Thursday, 23 May 2024 at 18:50
> > To: dev@flink.apache.org <de...@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 <to...@gmail.com>
> wrote:
> >
> > > Thanks, Alex.
> > >
> > > I see one task that needs to be done once the FLIP is approved, which
> I'd
> > > suggest to also mention in the: To explain the LTS policy to users on
> > > website / documentation (because FLIP is developer-facing) before /
> upon
> > > releasing 1.20.
> > >
> > > Other than that, the FLIP LGTM.
> > >
> > > Best,
> > >
> > > Xintong
> > >
> > >
> > >
> > > On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> > > alexander.fedulov@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 <19...@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 <
> > > martijnvisser@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 <19...@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 <
> > > > > martijnvisser@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
> > > > > > > > <al...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi everyone,
> > > > > > > > >
> > > > > > > > > As we progress with the 1.19 release, which might
> potentially
> > > > > > (although
> > > > > > > > not
> > > > > > > > > likely) be the last in the 1.x line, I'd like to revive our
> > > > > > discussion on
> > > > > > > > > the
> > > > > > > > > LTS support matter. There is a general consensus that due
> to
> > > > > > breaking API
> > > > > > > > > changes in 2.0, extending bug fixes support by designating
> an
> > > LTS
> > > > > > release
> > > > > > > > > is
> > > > > > > > > something we want to do.
> > > > > > > > >
> > > > > > > > > To summarize, the approaches we've considered are:
> > > > > > > > >
> > > > > > > > > Time-based: The last release of the 1.x line gets a clear
> > > > > end-of-life
> > > > > > > > date
> > > > > > > > > (2 years).
> > > > > > > > > Release-based: The last release of the 1.x line gets
> support
> > > for
> > > > 4
> > > > > > minor
> > > > > > > > > releases in the 2.x line. The exact time is unknown, but we
> > > > assume
> > > > > > it to
> > > > > > > > be
> > > > > > > > > roughly 2 years.
> > > > > > > > > LTS-to-LTS release: The last release of the 1.x line is
> > > supported
> > > > > > until
> > > > > > > > the
> > > > > > > > > last release in the 2.x line is designated as LTS.
> > > > > > > > >
> > > > > > > > > We need to strike a balance between being user-friendly and
> > > > nudging
> > > > > > > > people
> > > > > > > > > to
> > > > > > > > > upgrade. From that perspective, option 1 is my favorite -
> we
> > > all
> > > > > know
> > > > > > > > that
> > > > > > > > > having a clear deadline works wonders in motivating action.
> > At
> > > > the
> > > > > > same
> > > > > > > > > time,
> > > > > > > > > I appreciate that we might not want to introduce new kinds
> of
> > > > > > procedures,
> > > > > > > > > so
> > > > > > > > > option 2 would be my second choice, provided we also
> > formulate
> > > it
> > > > > > like "4
> > > > > > > > > minor releases, at least 2 years" (in case the minor
> release
> > > > > cadence
> > > > > > > > > accelerates for some reason). I find option 3 a bit
> > problematic
> > > > > > since it
> > > > > > > > > gives no incentive to upgrade, and people who do not follow
> > > Flink
> > > > > > > > > development
> > > > > > > > > closely might be caught by surprise when we decide to bump
> > the
> > > > > major
> > > > > > > > > version
> > > > > > > > > again.
> > > > > > > > >
> > > > > > > > > I'd like to open a vote to stamp the official decision, but
> > > > first,
> > > > > I
> > > > > > > > would
> > > > > > > > > like to understand if we can reach consensus on one of the
> > > > options
> > > > > > here,
> > > > > > > > or
> > > > > > > > > if
> > > > > > > > > we'll need to push that to a vote by presenting multiple
> > > options.
> > > > > > > > >
> > > > > > > > > Looking forward to hearing your thoughts on this matter.
> > > > > > > > >
> > > > > > > > > P.S.: 1.x and 2.x are just examples in this case; the
> > decision
> > > > also
> > > > > > > > > translates
> > > > > > > > > into a procedure for future major releases.
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Alex
> > > > > > > > >
> > > > > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge
> > > <jing@ververica.com.invalid
> > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Konstantin,
> > > > > > > > > >
> > > > > > > > > > What you said makes sense. Dropping modules is an
> efficient
> > > > > option
> > > > > > to
> > > > > > > > > > accelerate Flink evolution with acceptable function
> > > > regressions.
> > > > > We
> > > > > > > > should
> > > > > > > > > > do it constantly and strategically. On the other hand, we
> > > > should
> > > > > > point
> > > > > > > > out
> > > > > > > > > > the core modules that must be backward compatible when a
> > new
> > > > > major
> > > > > > > > version
> > > > > > > > > > is released.
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > > Jing
> > > > > > > > > >
> > > > > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > > > > <ji...@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
> <
> > > > > > > > > > knaufk@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
> > > > > > > > > > > > > > > <ji...@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.marton@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
> > > > <
> > > > > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > > > > xbjtdcq@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.fedulov@gmail.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Recently, there were a lot of
> > > discussions
> > > > > > about
> > > > > > > > the
> > > > > > > > > > > > > > deprecation
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > APIs for the upcoming 2.0 release.
> It
> > > > > appears
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > two
> > > > > > > > > > > > > > > main
> > > > > > > > > > > > > > > > > > > > motivations
> > > > > > > > > > > > > > > > > > > > > with opposing directions, causing
> > these
> > > > > > > > discussions
> > > > > > > > > > to
> > > > > > > > > > > > > remain
> > > > > > > > > > > > > > > > > > > unsettled.
> > > > > > > > > > > > > > > > > > > > On
> > > > > > > > > > > > > > > > > > > > > one hand, there's a desire to
> finally
> > > > trim
> > > > > a
> > > > > > wide
> > > > > > > > > > range
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > legacy
> > > > > > > > > > > > > > > > > > APIs,
> > > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > lingering around since the
> beginning
> > of
> > > > the
> > > > > > 1.x
> > > > > > > > > > release
> > > > > > > > > > > > > line
> > > > > > > > > > > > > > > (as
> > > > > > > > > > > > > > > > > far
> > > > > > > > > > > > > > > > > > > > back as
> > > > > > > > > > > > > > > > > > > > > 2016). On the other hand, there is
> a
> > > > > > commitment
> > > > > > > > to
> > > > > > > > > > > uphold
> > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > guarantees
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > the users, ensuring a smooth
> > > transition.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I believe we could reconcile these
> > two
> > > > > > > > motivations.
> > > > > > > > > > My
> > > > > > > > > > > > > > > > proposition
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > designate the final release of the
> > 1.x
> > > > > > timeline
> > > > > > > > as a
> > > > > > > > > > > > > > Long-Term
> > > > > > > > > > > > > > > > > > Support
> > > > > > > > > > > > > > > > > > > > (LTS)
> > > > > > > > > > > > > > > > > > > > > release. By doing so, we would:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 1. Enable more efficient cleanup
> and
> > be
> > > > > > > > liberated to
> > > > > > > > > > > > > > introduce
> > > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > > > > > changes, paving the way for
> greater
> > > > > > innovation
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > 2.0
> > > > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > > > > > 2. Sustain a positive user
> experience
> > > by
> > > > > > granting
> > > > > > > > > > > enough
> > > > > > > > > > > > > time
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > > > introduced in 2.0 to stabilize,
> > > > allowing
> > > > > > users
> > > > > > > > to
> > > > > > > > > > > > > > confidently
> > > > > > > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > > > > > > > their production code to the new
> > > > release.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I look forward to hearing your
> > thoughts
> > > > on
> > > > > > this
> > > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Best Regards,
> > > > > > > > > > > > > > > > > > > > > Alex
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > Unless otherwise stated above:
> >
> > IBM United Kingdom Limited
> > Registered in England and Wales with number 741598
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> >
>
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Alexander Fedulov <al...@gmail.com>.
@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 <ma...@apache.org>
wrote:
> Hi David,
>
> > If there is a maintainer willing to merge backported features to v1, as
> it is important to some part of the community, this should be allowed, as
> different parts of the community have different priorities and timelines,
>
> I don't think this is a good idea. Backporting a feature can cause issues
> in other components that might be outside the span of expertise of the
> maintainer that backported said feature, causing the overall stability to
> be degraded. I think our starting point should be "We don't backport
> features, unless discussed and agreed on the Dev mailing list". That still
> opens up the ability to backport features but makes it clear where the bar
> lies.
>
> Best regards,
>
> Martijn
>
> On Fri, May 24, 2024 at 11:21 AM David Radley <da...@uk.ibm.com>
> wrote:
>
> > Hi,
> > I agree with Martijn that we only put features into version 2. Back
> > porting to v1 should not be business as usual for features, only for
> > security and stability changes.
> >
> > If there is a maintainer willing to merge backported features to v1, as
> it
> > is important to some part of the community, this should be allowed, as
> > different parts of the community have different priorities and timelines,
> > Kind regards, David.
> >
> >
> > From: Alexander Fedulov <al...@gmail.com>
> > Date: Thursday, 23 May 2024 at 18:50
> > To: dev@flink.apache.org <de...@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 <to...@gmail.com>
> wrote:
> >
> > > Thanks, Alex.
> > >
> > > I see one task that needs to be done once the FLIP is approved, which
> I'd
> > > suggest to also mention in the: To explain the LTS policy to users on
> > > website / documentation (because FLIP is developer-facing) before /
> upon
> > > releasing 1.20.
> > >
> > > Other than that, the FLIP LGTM.
> > >
> > > Best,
> > >
> > > Xintong
> > >
> > >
> > >
> > > On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> > > alexander.fedulov@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 <19...@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 <
> > > martijnvisser@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 <19...@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 <
> > > > > martijnvisser@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
> > > > > > > > <al...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi everyone,
> > > > > > > > >
> > > > > > > > > As we progress with the 1.19 release, which might
> potentially
> > > > > > (although
> > > > > > > > not
> > > > > > > > > likely) be the last in the 1.x line, I'd like to revive our
> > > > > > discussion on
> > > > > > > > > the
> > > > > > > > > LTS support matter. There is a general consensus that due
> to
> > > > > > breaking API
> > > > > > > > > changes in 2.0, extending bug fixes support by designating
> an
> > > LTS
> > > > > > release
> > > > > > > > > is
> > > > > > > > > something we want to do.
> > > > > > > > >
> > > > > > > > > To summarize, the approaches we've considered are:
> > > > > > > > >
> > > > > > > > > Time-based: The last release of the 1.x line gets a clear
> > > > > end-of-life
> > > > > > > > date
> > > > > > > > > (2 years).
> > > > > > > > > Release-based: The last release of the 1.x line gets
> support
> > > for
> > > > 4
> > > > > > minor
> > > > > > > > > releases in the 2.x line. The exact time is unknown, but we
> > > > assume
> > > > > > it to
> > > > > > > > be
> > > > > > > > > roughly 2 years.
> > > > > > > > > LTS-to-LTS release: The last release of the 1.x line is
> > > supported
> > > > > > until
> > > > > > > > the
> > > > > > > > > last release in the 2.x line is designated as LTS.
> > > > > > > > >
> > > > > > > > > We need to strike a balance between being user-friendly and
> > > > nudging
> > > > > > > > people
> > > > > > > > > to
> > > > > > > > > upgrade. From that perspective, option 1 is my favorite -
> we
> > > all
> > > > > know
> > > > > > > > that
> > > > > > > > > having a clear deadline works wonders in motivating action.
> > At
> > > > the
> > > > > > same
> > > > > > > > > time,
> > > > > > > > > I appreciate that we might not want to introduce new kinds
> of
> > > > > > procedures,
> > > > > > > > > so
> > > > > > > > > option 2 would be my second choice, provided we also
> > formulate
> > > it
> > > > > > like "4
> > > > > > > > > minor releases, at least 2 years" (in case the minor
> release
> > > > > cadence
> > > > > > > > > accelerates for some reason). I find option 3 a bit
> > problematic
> > > > > > since it
> > > > > > > > > gives no incentive to upgrade, and people who do not follow
> > > Flink
> > > > > > > > > development
> > > > > > > > > closely might be caught by surprise when we decide to bump
> > the
> > > > > major
> > > > > > > > > version
> > > > > > > > > again.
> > > > > > > > >
> > > > > > > > > I'd like to open a vote to stamp the official decision, but
> > > > first,
> > > > > I
> > > > > > > > would
> > > > > > > > > like to understand if we can reach consensus on one of the
> > > > options
> > > > > > here,
> > > > > > > > or
> > > > > > > > > if
> > > > > > > > > we'll need to push that to a vote by presenting multiple
> > > options.
> > > > > > > > >
> > > > > > > > > Looking forward to hearing your thoughts on this matter.
> > > > > > > > >
> > > > > > > > > P.S.: 1.x and 2.x are just examples in this case; the
> > decision
> > > > also
> > > > > > > > > translates
> > > > > > > > > into a procedure for future major releases.
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Alex
> > > > > > > > >
> > > > > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge
> > > <jing@ververica.com.invalid
> > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Konstantin,
> > > > > > > > > >
> > > > > > > > > > What you said makes sense. Dropping modules is an
> efficient
> > > > > option
> > > > > > to
> > > > > > > > > > accelerate Flink evolution with acceptable function
> > > > regressions.
> > > > > We
> > > > > > > > should
> > > > > > > > > > do it constantly and strategically. On the other hand, we
> > > > should
> > > > > > point
> > > > > > > > out
> > > > > > > > > > the core modules that must be backward compatible when a
> > new
> > > > > major
> > > > > > > > version
> > > > > > > > > > is released.
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > > Jing
> > > > > > > > > >
> > > > > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > > > > <ji...@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
> <
> > > > > > > > > > knaufk@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
> > > > > > > > > > > > > > > <ji...@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.marton@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
> > > > <
> > > > > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > > > > xbjtdcq@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.fedulov@gmail.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Recently, there were a lot of
> > > discussions
> > > > > > about
> > > > > > > > the
> > > > > > > > > > > > > > deprecation
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > APIs for the upcoming 2.0 release.
> It
> > > > > appears
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > two
> > > > > > > > > > > > > > > main
> > > > > > > > > > > > > > > > > > > > motivations
> > > > > > > > > > > > > > > > > > > > > with opposing directions, causing
> > these
> > > > > > > > discussions
> > > > > > > > > > to
> > > > > > > > > > > > > remain
> > > > > > > > > > > > > > > > > > > unsettled.
> > > > > > > > > > > > > > > > > > > > On
> > > > > > > > > > > > > > > > > > > > > one hand, there's a desire to
> finally
> > > > trim
> > > > > a
> > > > > > wide
> > > > > > > > > > range
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > legacy
> > > > > > > > > > > > > > > > > > APIs,
> > > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > lingering around since the
> beginning
> > of
> > > > the
> > > > > > 1.x
> > > > > > > > > > release
> > > > > > > > > > > > > line
> > > > > > > > > > > > > > > (as
> > > > > > > > > > > > > > > > > far
> > > > > > > > > > > > > > > > > > > > back as
> > > > > > > > > > > > > > > > > > > > > 2016). On the other hand, there is
> a
> > > > > > commitment
> > > > > > > > to
> > > > > > > > > > > uphold
> > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > guarantees
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > the users, ensuring a smooth
> > > transition.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I believe we could reconcile these
> > two
> > > > > > > > motivations.
> > > > > > > > > > My
> > > > > > > > > > > > > > > > proposition
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > designate the final release of the
> > 1.x
> > > > > > timeline
> > > > > > > > as a
> > > > > > > > > > > > > > Long-Term
> > > > > > > > > > > > > > > > > > Support
> > > > > > > > > > > > > > > > > > > > (LTS)
> > > > > > > > > > > > > > > > > > > > > release. By doing so, we would:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 1. Enable more efficient cleanup
> and
> > be
> > > > > > > > liberated to
> > > > > > > > > > > > > > introduce
> > > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > > > > > changes, paving the way for
> greater
> > > > > > innovation
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > 2.0
> > > > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > > > > > 2. Sustain a positive user
> experience
> > > by
> > > > > > granting
> > > > > > > > > > > enough
> > > > > > > > > > > > > time
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > > > introduced in 2.0 to stabilize,
> > > > allowing
> > > > > > users
> > > > > > > > to
> > > > > > > > > > > > > > confidently
> > > > > > > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > > > > > > > their production code to the new
> > > > release.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I look forward to hearing your
> > thoughts
> > > > on
> > > > > > this
> > > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Best Regards,
> > > > > > > > > > > > > > > > > > > > > Alex
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > Unless otherwise stated above:
> >
> > IBM United Kingdom Limited
> > Registered in England and Wales with number 741598
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> >
>
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Martijn Visser <ma...@apache.org>.
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 <da...@uk.ibm.com>
wrote:
> Hi,
> I agree with Martijn that we only put features into version 2. Back
> porting to v1 should not be business as usual for features, only for
> security and stability changes.
>
> If there is a maintainer willing to merge backported features to v1, as it
> is important to some part of the community, this should be allowed, as
> different parts of the community have different priorities and timelines,
> Kind regards, David.
>
>
> From: Alexander Fedulov <al...@gmail.com>
> Date: Thursday, 23 May 2024 at 18:50
> To: dev@flink.apache.org <de...@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 <to...@gmail.com> wrote:
>
> > Thanks, Alex.
> >
> > I see one task that needs to be done once the FLIP is approved, which I'd
> > suggest to also mention in the: To explain the LTS policy to users on
> > website / documentation (because FLIP is developer-facing) before / upon
> > releasing 1.20.
> >
> > Other than that, the FLIP LGTM.
> >
> > Best,
> >
> > Xintong
> >
> >
> >
> > On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> > alexander.fedulov@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 <19...@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 <
> > martijnvisser@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 <19...@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 <
> > > > martijnvisser@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
> > > > > > > <al...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi everyone,
> > > > > > > >
> > > > > > > > As we progress with the 1.19 release, which might potentially
> > > > > (although
> > > > > > > not
> > > > > > > > likely) be the last in the 1.x line, I'd like to revive our
> > > > > discussion on
> > > > > > > > the
> > > > > > > > LTS support matter. There is a general consensus that due to
> > > > > breaking API
> > > > > > > > changes in 2.0, extending bug fixes support by designating an
> > LTS
> > > > > release
> > > > > > > > is
> > > > > > > > something we want to do.
> > > > > > > >
> > > > > > > > To summarize, the approaches we've considered are:
> > > > > > > >
> > > > > > > > Time-based: The last release of the 1.x line gets a clear
> > > > end-of-life
> > > > > > > date
> > > > > > > > (2 years).
> > > > > > > > Release-based: The last release of the 1.x line gets support
> > for
> > > 4
> > > > > minor
> > > > > > > > releases in the 2.x line. The exact time is unknown, but we
> > > assume
> > > > > it to
> > > > > > > be
> > > > > > > > roughly 2 years.
> > > > > > > > LTS-to-LTS release: The last release of the 1.x line is
> > supported
> > > > > until
> > > > > > > the
> > > > > > > > last release in the 2.x line is designated as LTS.
> > > > > > > >
> > > > > > > > We need to strike a balance between being user-friendly and
> > > nudging
> > > > > > > people
> > > > > > > > to
> > > > > > > > upgrade. From that perspective, option 1 is my favorite - we
> > all
> > > > know
> > > > > > > that
> > > > > > > > having a clear deadline works wonders in motivating action.
> At
> > > the
> > > > > same
> > > > > > > > time,
> > > > > > > > I appreciate that we might not want to introduce new kinds of
> > > > > procedures,
> > > > > > > > so
> > > > > > > > option 2 would be my second choice, provided we also
> formulate
> > it
> > > > > like "4
> > > > > > > > minor releases, at least 2 years" (in case the minor release
> > > > cadence
> > > > > > > > accelerates for some reason). I find option 3 a bit
> problematic
> > > > > since it
> > > > > > > > gives no incentive to upgrade, and people who do not follow
> > Flink
> > > > > > > > development
> > > > > > > > closely might be caught by surprise when we decide to bump
> the
> > > > major
> > > > > > > > version
> > > > > > > > again.
> > > > > > > >
> > > > > > > > I'd like to open a vote to stamp the official decision, but
> > > first,
> > > > I
> > > > > > > would
> > > > > > > > like to understand if we can reach consensus on one of the
> > > options
> > > > > here,
> > > > > > > or
> > > > > > > > if
> > > > > > > > we'll need to push that to a vote by presenting multiple
> > options.
> > > > > > > >
> > > > > > > > Looking forward to hearing your thoughts on this matter.
> > > > > > > >
> > > > > > > > P.S.: 1.x and 2.x are just examples in this case; the
> decision
> > > also
> > > > > > > > translates
> > > > > > > > into a procedure for future major releases.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge
> > <jing@ververica.com.invalid
> > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Konstantin,
> > > > > > > > >
> > > > > > > > > What you said makes sense. Dropping modules is an efficient
> > > > option
> > > > > to
> > > > > > > > > accelerate Flink evolution with acceptable function
> > > regressions.
> > > > We
> > > > > > > should
> > > > > > > > > do it constantly and strategically. On the other hand, we
> > > should
> > > > > point
> > > > > > > out
> > > > > > > > > the core modules that must be backward compatible when a
> new
> > > > major
> > > > > > > version
> > > > > > > > > is released.
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > > Jing
> > > > > > > > >
> > > > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > > > <ji...@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 <
> > > > > > > > > knaufk@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
> > > > > > > > > > > > > > <ji...@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.marton@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
> > > <
> > > > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > > > xbjtdcq@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.fedulov@gmail.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Recently, there were a lot of
> > discussions
> > > > > about
> > > > > > > the
> > > > > > > > > > > > > deprecation
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > APIs for the upcoming 2.0 release. It
> > > > appears
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > two
> > > > > > > > > > > > > > main
> > > > > > > > > > > > > > > > > > > motivations
> > > > > > > > > > > > > > > > > > > > with opposing directions, causing
> these
> > > > > > > discussions
> > > > > > > > > to
> > > > > > > > > > > > remain
> > > > > > > > > > > > > > > > > > unsettled.
> > > > > > > > > > > > > > > > > > > On
> > > > > > > > > > > > > > > > > > > > one hand, there's a desire to finally
> > > trim
> > > > a
> > > > > wide
> > > > > > > > > range
> > > > > > > > > > > of
> > > > > > > > > > > > > > legacy
> > > > > > > > > > > > > > > > > APIs,
> > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > lingering around since the beginning
> of
> > > the
> > > > > 1.x
> > > > > > > > > release
> > > > > > > > > > > > line
> > > > > > > > > > > > > > (as
> > > > > > > > > > > > > > > > far
> > > > > > > > > > > > > > > > > > > back as
> > > > > > > > > > > > > > > > > > > > 2016). On the other hand, there is a
> > > > > commitment
> > > > > > > to
> > > > > > > > > > uphold
> > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > guarantees
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > the users, ensuring a smooth
> > transition.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I believe we could reconcile these
> two
> > > > > > > motivations.
> > > > > > > > > My
> > > > > > > > > > > > > > > proposition
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > designate the final release of the
> 1.x
> > > > > timeline
> > > > > > > as a
> > > > > > > > > > > > > Long-Term
> > > > > > > > > > > > > > > > > Support
> > > > > > > > > > > > > > > > > > > (LTS)
> > > > > > > > > > > > > > > > > > > > release. By doing so, we would:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 1. Enable more efficient cleanup and
> be
> > > > > > > liberated to
> > > > > > > > > > > > > introduce
> > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > > > > changes, paving the way for greater
> > > > > innovation
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > 2.0
> > > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > > > > 2. Sustain a positive user experience
> > by
> > > > > granting
> > > > > > > > > > enough
> > > > > > > > > > > > time
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > > introduced in 2.0 to stabilize,
> > > allowing
> > > > > users
> > > > > > > to
> > > > > > > > > > > > > confidently
> > > > > > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > > > > > > their production code to the new
> > > release.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I look forward to hearing your
> thoughts
> > > on
> > > > > this
> > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Best Regards,
> > > > > > > > > > > > > > > > > > > > Alex
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
RE: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by David Radley <da...@uk.ibm.com>.
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 <al...@gmail.com>
Date: Thursday, 23 May 2024 at 18:50
To: dev@flink.apache.org <de...@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 <to...@gmail.com> wrote:
> Thanks, Alex.
>
> I see one task that needs to be done once the FLIP is approved, which I'd
> suggest to also mention in the: To explain the LTS policy to users on
> website / documentation (because FLIP is developer-facing) before / upon
> releasing 1.20.
>
> Other than that, the FLIP LGTM.
>
> Best,
>
> Xintong
>
>
>
> On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> alexander.fedulov@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 <19...@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 <
> martijnvisser@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 <19...@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 <
> > > martijnvisser@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
> > > > > > <al...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi everyone,
> > > > > > >
> > > > > > > As we progress with the 1.19 release, which might potentially
> > > > (although
> > > > > > not
> > > > > > > likely) be the last in the 1.x line, I'd like to revive our
> > > > discussion on
> > > > > > > the
> > > > > > > LTS support matter. There is a general consensus that due to
> > > > breaking API
> > > > > > > changes in 2.0, extending bug fixes support by designating an
> LTS
> > > > release
> > > > > > > is
> > > > > > > something we want to do.
> > > > > > >
> > > > > > > To summarize, the approaches we've considered are:
> > > > > > >
> > > > > > > Time-based: The last release of the 1.x line gets a clear
> > > end-of-life
> > > > > > date
> > > > > > > (2 years).
> > > > > > > Release-based: The last release of the 1.x line gets support
> for
> > 4
> > > > minor
> > > > > > > releases in the 2.x line. The exact time is unknown, but we
> > assume
> > > > it to
> > > > > > be
> > > > > > > roughly 2 years.
> > > > > > > LTS-to-LTS release: The last release of the 1.x line is
> supported
> > > > until
> > > > > > the
> > > > > > > last release in the 2.x line is designated as LTS.
> > > > > > >
> > > > > > > We need to strike a balance between being user-friendly and
> > nudging
> > > > > > people
> > > > > > > to
> > > > > > > upgrade. From that perspective, option 1 is my favorite - we
> all
> > > know
> > > > > > that
> > > > > > > having a clear deadline works wonders in motivating action. At
> > the
> > > > same
> > > > > > > time,
> > > > > > > I appreciate that we might not want to introduce new kinds of
> > > > procedures,
> > > > > > > so
> > > > > > > option 2 would be my second choice, provided we also formulate
> it
> > > > like "4
> > > > > > > minor releases, at least 2 years" (in case the minor release
> > > cadence
> > > > > > > accelerates for some reason). I find option 3 a bit problematic
> > > > since it
> > > > > > > gives no incentive to upgrade, and people who do not follow
> Flink
> > > > > > > development
> > > > > > > closely might be caught by surprise when we decide to bump the
> > > major
> > > > > > > version
> > > > > > > again.
> > > > > > >
> > > > > > > I'd like to open a vote to stamp the official decision, but
> > first,
> > > I
> > > > > > would
> > > > > > > like to understand if we can reach consensus on one of the
> > options
> > > > here,
> > > > > > or
> > > > > > > if
> > > > > > > we'll need to push that to a vote by presenting multiple
> options.
> > > > > > >
> > > > > > > Looking forward to hearing your thoughts on this matter.
> > > > > > >
> > > > > > > P.S.: 1.x and 2.x are just examples in this case; the decision
> > also
> > > > > > > translates
> > > > > > > into a procedure for future major releases.
> > > > > > >
> > > > > > > Best,
> > > > > > > Alex
> > > > > > >
> > > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge
> <jing@ververica.com.invalid
> > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Konstantin,
> > > > > > > >
> > > > > > > > What you said makes sense. Dropping modules is an efficient
> > > option
> > > > to
> > > > > > > > accelerate Flink evolution with acceptable function
> > regressions.
> > > We
> > > > > > should
> > > > > > > > do it constantly and strategically. On the other hand, we
> > should
> > > > point
> > > > > > out
> > > > > > > > the core modules that must be backward compatible when a new
> > > major
> > > > > > version
> > > > > > > > is released.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Jing
> > > > > > > >
> > > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > > <ji...@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 <
> > > > > > > > knaufk@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
> > > > > > > > > > > > > <ji...@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.marton@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
> > <
> > > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > > xbjtdcq@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.fedulov@gmail.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Recently, there were a lot of
> discussions
> > > > about
> > > > > > the
> > > > > > > > > > > > deprecation
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > APIs for the upcoming 2.0 release. It
> > > appears
> > > > > > there
> > > > > > > > are
> > > > > > > > > > two
> > > > > > > > > > > > > main
> > > > > > > > > > > > > > > > > > motivations
> > > > > > > > > > > > > > > > > > > with opposing directions, causing these
> > > > > > discussions
> > > > > > > > to
> > > > > > > > > > > remain
> > > > > > > > > > > > > > > > > unsettled.
> > > > > > > > > > > > > > > > > > On
> > > > > > > > > > > > > > > > > > > one hand, there's a desire to finally
> > trim
> > > a
> > > > wide
> > > > > > > > range
> > > > > > > > > > of
> > > > > > > > > > > > > legacy
> > > > > > > > > > > > > > > > APIs,
> > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > lingering around since the beginning of
> > the
> > > > 1.x
> > > > > > > > release
> > > > > > > > > > > line
> > > > > > > > > > > > > (as
> > > > > > > > > > > > > > > far
> > > > > > > > > > > > > > > > > > back as
> > > > > > > > > > > > > > > > > > > 2016). On the other hand, there is a
> > > > commitment
> > > > > > to
> > > > > > > > > uphold
> > > > > > > > > > > our
> > > > > > > > > > > > > > > > > guarantees
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > the users, ensuring a smooth
> transition.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I believe we could reconcile these two
> > > > > > motivations.
> > > > > > > > My
> > > > > > > > > > > > > > proposition
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > designate the final release of the 1.x
> > > > timeline
> > > > > > as a
> > > > > > > > > > > > Long-Term
> > > > > > > > > > > > > > > > Support
> > > > > > > > > > > > > > > > > > (LTS)
> > > > > > > > > > > > > > > > > > > release. By doing so, we would:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1. Enable more efficient cleanup and be
> > > > > > liberated to
> > > > > > > > > > > > introduce
> > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > > > changes, paving the way for greater
> > > > innovation
> > > > > > in
> > > > > > > > the
> > > > > > > > > > 2.0
> > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > > > 2. Sustain a positive user experience
> by
> > > > granting
> > > > > > > > > enough
> > > > > > > > > > > time
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > introduced in 2.0 to stabilize,
> > allowing
> > > > users
> > > > > > to
> > > > > > > > > > > > confidently
> > > > > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > > > > > their production code to the new
> > release.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I look forward to hearing your thoughts
> > on
> > > > this
> > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Best Regards,
> > > > > > > > > > > > > > > > > > > Alex
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > https://twitter.com/snntrable
> > > > > > > > > > > > > https://github.com/knaufk
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
>
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Alexander Fedulov <al...@gmail.com>.
Good point, Xintong, I incorporated this item into the FLIP.
Best,
Alex
On Wed, 22 May 2024 at 10:37, Xintong Song <to...@gmail.com> wrote:
> Thanks, Alex.
>
> I see one task that needs to be done once the FLIP is approved, which I'd
> suggest to also mention in the: To explain the LTS policy to users on
> website / documentation (because FLIP is developer-facing) before / upon
> releasing 1.20.
>
> Other than that, the FLIP LGTM.
>
> Best,
>
> Xintong
>
>
>
> On Tue, May 21, 2024 at 5:21 PM Alexander Fedulov <
> alexander.fedulov@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 <19...@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 <
> martijnvisser@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 <19...@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 <
> > > martijnvisser@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
> > > > > > <al...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi everyone,
> > > > > > >
> > > > > > > As we progress with the 1.19 release, which might potentially
> > > > (although
> > > > > > not
> > > > > > > likely) be the last in the 1.x line, I'd like to revive our
> > > > discussion on
> > > > > > > the
> > > > > > > LTS support matter. There is a general consensus that due to
> > > > breaking API
> > > > > > > changes in 2.0, extending bug fixes support by designating an
> LTS
> > > > release
> > > > > > > is
> > > > > > > something we want to do.
> > > > > > >
> > > > > > > To summarize, the approaches we've considered are:
> > > > > > >
> > > > > > > Time-based: The last release of the 1.x line gets a clear
> > > end-of-life
> > > > > > date
> > > > > > > (2 years).
> > > > > > > Release-based: The last release of the 1.x line gets support
> for
> > 4
> > > > minor
> > > > > > > releases in the 2.x line. The exact time is unknown, but we
> > assume
> > > > it to
> > > > > > be
> > > > > > > roughly 2 years.
> > > > > > > LTS-to-LTS release: The last release of the 1.x line is
> supported
> > > > until
> > > > > > the
> > > > > > > last release in the 2.x line is designated as LTS.
> > > > > > >
> > > > > > > We need to strike a balance between being user-friendly and
> > nudging
> > > > > > people
> > > > > > > to
> > > > > > > upgrade. From that perspective, option 1 is my favorite - we
> all
> > > know
> > > > > > that
> > > > > > > having a clear deadline works wonders in motivating action. At
> > the
> > > > same
> > > > > > > time,
> > > > > > > I appreciate that we might not want to introduce new kinds of
> > > > procedures,
> > > > > > > so
> > > > > > > option 2 would be my second choice, provided we also formulate
> it
> > > > like "4
> > > > > > > minor releases, at least 2 years" (in case the minor release
> > > cadence
> > > > > > > accelerates for some reason). I find option 3 a bit problematic
> > > > since it
> > > > > > > gives no incentive to upgrade, and people who do not follow
> Flink
> > > > > > > development
> > > > > > > closely might be caught by surprise when we decide to bump the
> > > major
> > > > > > > version
> > > > > > > again.
> > > > > > >
> > > > > > > I'd like to open a vote to stamp the official decision, but
> > first,
> > > I
> > > > > > would
> > > > > > > like to understand if we can reach consensus on one of the
> > options
> > > > here,
> > > > > > or
> > > > > > > if
> > > > > > > we'll need to push that to a vote by presenting multiple
> options.
> > > > > > >
> > > > > > > Looking forward to hearing your thoughts on this matter.
> > > > > > >
> > > > > > > P.S.: 1.x and 2.x are just examples in this case; the decision
> > also
> > > > > > > translates
> > > > > > > into a procedure for future major releases.
> > > > > > >
> > > > > > > Best,
> > > > > > > Alex
> > > > > > >
> > > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge
> <jing@ververica.com.invalid
> > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Konstantin,
> > > > > > > >
> > > > > > > > What you said makes sense. Dropping modules is an efficient
> > > option
> > > > to
> > > > > > > > accelerate Flink evolution with acceptable function
> > regressions.
> > > We
> > > > > > should
> > > > > > > > do it constantly and strategically. On the other hand, we
> > should
> > > > point
> > > > > > out
> > > > > > > > the core modules that must be backward compatible when a new
> > > major
> > > > > > version
> > > > > > > > is released.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Jing
> > > > > > > >
> > > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > > <ji...@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 <
> > > > > > > > knaufk@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
> > > > > > > > > > > > > <ji...@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.marton@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
> > <
> > > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > > xbjtdcq@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.fedulov@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
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Posted by Xintong Song <to...@gmail.com>.
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.fedulov@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 <19...@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 <martijnvisser@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 <19...@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 <
> > martijnvisser@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
> > > > > <al...@gmail.com> wrote:
> > > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > As we progress with the 1.19 release, which might potentially
> > > (although
> > > > > not
> > > > > > likely) be the last in the 1.x line, I'd like to revive our
> > > discussion on
> > > > > > the
> > > > > > LTS support matter. There is a general consensus that due to
> > > breaking API
> > > > > > changes in 2.0, extending bug fixes support by designating an LTS
> > > release
> > > > > > is
> > > > > > something we want to do.
> > > > > >
> > > > > > To summarize, the approaches we've considered are:
> > > > > >
> > > > > > Time-based: The last release of the 1.x line gets a clear
> > end-of-life
> > > > > date
> > > > > > (2 years).
> > > > > > Release-based: The last release of the 1.x line gets support for
> 4
> > > minor
> > > > > > releases in the 2.x line. The exact time is unknown, but we
> assume
> > > it to
> > > > > be
> > > > > > roughly 2 years.
> > > > > > LTS-to-LTS release: The last release of the 1.x line is supported
> > > until
> > > > > the
> > > > > > last release in the 2.x line is designated as LTS.
> > > > > >
> > > > > > We need to strike a balance between being user-friendly and
> nudging
> > > > > people
> > > > > > to
> > > > > > upgrade. From that perspective, option 1 is my favorite - we all
> > know
> > > > > that
> > > > > > having a clear deadline works wonders in motivating action. At
> the
> > > same
> > > > > > time,
> > > > > > I appreciate that we might not want to introduce new kinds of
> > > procedures,
> > > > > > so
> > > > > > option 2 would be my second choice, provided we also formulate it
> > > like "4
> > > > > > minor releases, at least 2 years" (in case the minor release
> > cadence
> > > > > > accelerates for some reason). I find option 3 a bit problematic
> > > since it
> > > > > > gives no incentive to upgrade, and people who do not follow Flink
> > > > > > development
> > > > > > closely might be caught by surprise when we decide to bump the
> > major
> > > > > > version
> > > > > > again.
> > > > > >
> > > > > > I'd like to open a vote to stamp the official decision, but
> first,
> > I
> > > > > would
> > > > > > like to understand if we can reach consensus on one of the
> options
> > > here,
> > > > > or
> > > > > > if
> > > > > > we'll need to push that to a vote by presenting multiple options.
> > > > > >
> > > > > > Looking forward to hearing your thoughts on this matter.
> > > > > >
> > > > > > P.S.: 1.x and 2.x are just examples in this case; the decision
> also
> > > > > > translates
> > > > > > into a procedure for future major releases.
> > > > > >
> > > > > > Best,
> > > > > > Alex
> > > > > >
> > > > > > On Thu, 27 Jul 2023 at 17:32, Jing Ge <jing@ververica.com.invalid
> >
> > > > > wrote:
> > > > > >
> > > > > > > Hi Konstantin,
> > > > > > >
> > > > > > > What you said makes sense. Dropping modules is an efficient
> > option
> > > to
> > > > > > > accelerate Flink evolution with acceptable function
> regressions.
> > We
> > > > > should
> > > > > > > do it constantly and strategically. On the other hand, we
> should
> > > point
> > > > > out
> > > > > > > the core modules that must be backward compatible when a new
> > major
> > > > > version
> > > > > > > is released.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jing
> > > > > > >
> > > > > > > On Wed, Jul 26, 2023 at 10:52 PM Matthias Pohl
> > > > > > > <ma...@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.fedulov@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.pohl@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
> > > > > <ji...@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 <
> > > > > > > knaufk@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
> > > > > > > > > > > > <ji...@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.marton@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
> <
> > > > > > > > > > knaufk@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 <
> > > > > > > > > > > > > > > tonysong820@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 <
> > > > > > > > > xbjtdcq@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.fedulov@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
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
>