t;>> 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
>
there might be for back ports.
> > > Kind regards, David.
> > >
> > >
> > >
> > >
> > > From: Alexander Fedulov
> > > Date: Friday, 24 May 2024 at 14:07
> > > To: dev@flink.apache.org
> > > Subject: [EXTERNA
gt;
> >
> >
> > From: Alexander Fedulov
> > Date: Friday, 24 May 2024 at 14:07
> > To: dev@flink.apache.org
> > Subject: [EXTERNAL] Re: [DISCUSS] Proposing an LTS Release for the 1.x
> Line
> > @David
> > > I agree with Martijn that we only pu
anges.
> > >
> > > 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,
&g
egards, David.
> >
> >
> > From: Alexander Fedulov
> > Date: Thursday, 23 May 2024 at 18:50
> > To: dev@flink.apache.org
> > Subject: [EXTERNAL] Re: [DISCUSS] Proposing an LTS Release for the 1.x
> Line
> > Good point, Xintong, I incorporated this item int
gt;
> >
> > From: Alexander Fedulov
> > Date: Thursday, 23 May 2024 at 18:50
> > To: dev@flink.apache.org
> > Subject: [EXTERNAL] Re: [DISCUSS] Proposing an LTS Release for the 1.x
> Line
> > Good point, Xintong, I incorporated this item into the FLIP.
&
lines,
> Kind regards, David.
>
>
> From: Alexander Fedulov
> Date: Thursday, 23 May 2024 at 18:50
> To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
> Good point, Xintong, I incorporated this item into the FLI
, this should be allowed, as different
parts of the community have different priorities and timelines,
Kind regards, David.
From: Alexander Fedulov
Date: Thursday, 23 May 2024 at 18:50
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: [DISCUSS] Proposing an LTS Release for the 1.x Line
Good
Good point, Xintong, I incorporated this item into the FLIP.
Best,
Alex
On Wed, 22 May 2024 at 10:37, Xintong Song wrote:
> Thanks, Alex.
>
> I see one task that needs to be done once the FLIP is approved, which I'd
> suggest to also mention in the: To explain the LTS policy to users on
>
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
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
Thanks Martijn for the feedback!
Sounds make sense to me! And I don't have strong opinion that allow
backporting new features to 1.x.
Best,
Rui
On Mon, Jan 22, 2024 at 8:56 PM Martijn Visser
wrote:
> Hi Rui,
>
> I don't think that we should allow backporting of new features from
> the first
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
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
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
Hi Julian,
Could you please remove the duplicated "RE:" in the topic of the reply?
That way we can continue this discussion to the original thread.
(Apache deals with it correctly, but not all email clients/services do,
e.g. GMail)
Thanks,
Alex
On Tue, 5 Dec 2023 at 09:39, Payne, Julian
wrote:
Hey all,
Thanks for this proposal, I think it makes a lot of sense. I am, curious to
know what time horizon we would consider for LTS of 1.x. Customers value
knowing when versions will deprecate so they can build migration into their
planning and resourcing cycles, so I would be in favour of
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
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
I'm actually thinking about supporting the LTS release until the next LTS
/ major version bump. E.g., if 1.19 is a LTS, we provide support for it
for the entire 2.x series, until we bump to 3.0 and make the last 2.x minor
release the new LTS. This probably will not require much more effort than
>
> @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
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
Hi Jing,
> How could we help users and avoid this happening?
I don't think we will be able to avoid this in all cases. And I think
that's ok. Its always a trade-off between supporting new use cases and
moving the project forward and backwards compatibility (in a broad sense).
For example, we
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
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
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
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
Hi team,
+1 for supporting the last 1.x for a longer than usual period of time and
limiting it to bugfixes. I would suggest supporting it for double the usual
amount of time (4 minor releases).
On Tue, Jul 25, 2023 at 9:25 AM Konstantin Knauf wrote:
> Hi Alex,
>
> yes, I think, it makes sense
Hi Alex,
yes, I think, it makes sense to support the last 1.x release longer than
usual. This should be limited to bugfixes in my opinion.
Best,
Konstantin
Am Di., 25. Juli 2023 um 07:07 Uhr schrieb Xintong Song <
tonysong...@gmail.com>:
> Hi Alex,
>
> Providing a longer supporting period for
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
+1, it’s pretty necessary especially we deprecated so many APIs in 1.18 and
plan to remove in 2.0.
The 1.19 should be a proper version for LTS Release.
Best,
Leonard
> On Jul 25, 2023, at 3:30 AM, Alexander Fedulov
> wrote:
>
> Hello everyone,
>
> Recently, there were a lot of discussions
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
32 matches
Mail list logo
