ream API, such as:
> > >> >> > ** Having a coherent and well designed API
> > >> >> > ** Decouple the API into API-only modules, so no more cyclic
> > >> >> dependencies
> > >> >> > and leaking of non-APIs, including Kryo
> > >>
m 10:16 schreef David Morávek >
> >> >> >
> >> >> > > Hi,
> >> >> > >
> >> >> > > Great to see this topic moving forward; I agree it's long
> overdue.
> >> >> > >
> >> >> >
s and APIs that hold
>> us
>> >> > > back.
>> >> > >
>> >> > > Some items in the doc (Key Features section) don't tick these boxes
>> >> for
>> >> > me,
>> >> > > as they could also be implemented
d.
> >> > >
> >> > > Best,
> >> > > D.
> >> > >
> >> > >
> >> > > On Wed, Apr 26, 2023 at 2:33 PM DONG Weike >
> >> > > wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > It is thr
> It is thrilling to see the foreseeable upcoming rollouts of Flink
>> 2.x
>> > > > releases, and I believe that this roadmap can take Flink to the next
>> > > stage
>> > > > of a top-of-notch unified streaming & batch computing engine.
>
x and rely
> on
> > > > various third-party connectors written with legacy APIs, one thing
> > that I
> > > > have concerns about is if, one day in the future, the community
> decides
> > > > that new features are only given to 2.x releases, could the last
> >
> of
> > > Flink 1.x be converted as an LTS version (backporting severe bug fixes
> > and
> > > critical security patches), so that existing users could have enough
> time
> > > to wait for third-party connectors to upgrade, test their programs on
> the
> > > Flink APIs, and avoid sudden loss of comm
severe bug fixes
> and
> > critical security patches), so that existing users could have enough time
> > to wait for third-party connectors to upgrade, test their programs on the
> > Flink APIs, and avoid sudden loss of community support.
> >
> > Just my two cents
en loss of community support.
>
> Just my two cents : )
>
> Best,
> Weike
>
> ____________
> 发件人: Xintong Song
> 发送时间: 2023年4月26日 20:01
> 收件人: dev
> 主题: Re: [DISCUSS] Planning Flink 2.0
>
> @Chesnay
>
>
> > Technically this implie
Best,
Weike
发件人: Xintong Song
发送时间: 2023年4月26日 20:01
收件人: dev
主题: Re: [DISCUSS] Planning Flink 2.0
@Chesnay
> Technically this implies that every minor release may contain breaking
> changes, which is exactly what users don't want.
It's not ne
@Chesnay
> Technically this implies that every minor release may contain breaking
> changes, which is exactly what users don't want.
It's not necessary to introduce the breaking chagnes immediately upon
reaching the minimum guaranteed stable time. If there are multiple changes
waiting for the s
+1 to everything Max said.
Gyula
On Wed, 26 Apr 2023 at 11:42, Maximilian Michels wrote:
> Thanks for starting the discussion, Jark and Xingtong!
>
> Flink 2.0 is long overdue. In the past, the expectations for such a
> release were unreasonably high. I think everybody had a different
> underst
Thanks for starting the discussion, Jark and Xingtong!
Flink 2.0 is long overdue. In the past, the expectations for such a
release were unreasonably high. I think everybody had a different
understanding of what exactly the criteria were. This led to releasing
18 minor releases for the current majo
> /Instead of defining compatibility guarantees as "this API won't
change in all 1.x/2.x series", what if we define it as "this API won't
change in the next 2/3 years"./
I can see some benefits to this approach (all APIs having a fixed
minimum lifetime) but it's just gonna be difficult to comm
Thanks all for the positive feedback.
@Martijn
If we want to have that roadmap, should we consolidate this into a
> dedicated Confluence page over storing it in a Google doc?
>
Having a dedicated wiki page is definitely a good way for the roadmap
discussion. I haven't created one yet because it'
Thanks Xintong and Jark for kicking off the great discussion!
I checked the list carefully. The plans are detailed and most of the
problems are covered
Some of the ideas Chesnay mentioned, I think we should iterate in
small steps and collect feedback in time
Looking forward to the start of the wor
Thanks Xingtong and Jark for kicking off and driving the discussion! It is
really good to see we finally start talking about Flink 2.0. There are so
many great ideas that require breaking API changes and so many tech debts
need to be cleaned up. With the Flink 2.0 ahead, we will be more fast-paced
This is definitely a good discussion so have.
Some thoughts:
One aspect that wasn't mentioned is what this release means going
forward. I already waited a decade for 2.0; don't really want to wait
another one to see Flink 3.0.
We should discuss how regularly we will ship major releases from no
Hi all,
I think it's a great idea to have a concrete planning and roadmap
discussion on Flink 2.0. I've also thought on this topic previously and
would like to volunteer as one of the release managers.
A couple of initial thoughts:
* I'm assuming that as a desired outcome of this discussion thre
Hi Xintong and Jark,
Thanks for starting the discussion about Flink 2.0. This is indeed
something that people talk about all the time but without material actions
taken. It is good timing to kick off this effort, so we can bring Flink to
the next stage and move faster.
I'd also volunteer to be a
Thanks Xintong and Jark for kicking off the great discussion!
The time goes so fast, it is already the 10th anniversary of Flink as an Apache
project. Although I haven't gone through the proposal carefully, +1 for the
perfect release time and the release managers candidates.
Best,
Leonard
>
21 matches
Mail list logo
