>
> I'm not aware of any decision that has already been made by the community
> regarding after which 1.x minor release will we ship the 2.0 major release.
> I personally don't think it's feasible to avoid 1.19, and even 1.20
> depending on the progress.
Ok, thanks. That clarification helped. I h
Hi Matthias,
I'm not aware of any decision that has already been made by the community
regarding after which 1.x minor release will we ship the 2.0 major release.
I personally don't think it's feasible to avoid 1.19, and even 1.20
depending on the progress.
I also don't think we should push all t
Hi,
Thanks Matthias for starting this discussion and thanks Chesnay for the
clarification.
I don't want to hijack this discussion but I would suggest postponing the
1.18 feature freeze over postponing the deprecations to 1.19. If there are
some contributors who think it makes sense, I will raise
The issue isn't avoiding 1.19.
The issue is that if things aren't deprecated in 1.18 then for every
breaking change we have to start discussing exemptions from the API
deprecation process, which stipulates that all Public APIs must be
deprecated for at least 2 minor releases before they can be
Jing brought up a question in the FLIP-335 discussion thread [1] which I
want to move into a dedicated discussion thread as it's a bit more general:
How do we handle the deprecation process of Public APIs for Flink 2.0?
>
> I just have a related question: Do we need to create a FLIP each time
> whe
