+1 Sounds good! Four releases give a decent amount of time to migrate to the next Flink version.
On Tue, Sep 5, 2023 at 5:33 PM Őrhidi Mátyás <matyas.orh...@gmail.com> wrote: > > +1 > > On Tue, Sep 5, 2023 at 8:03 AM Thomas Weise <t...@apache.org> wrote: > > > +1, thanks for the proposal > > > > On Tue, Sep 5, 2023 at 8:13 AM Gyula Fóra <gyula.f...@gmail.com> wrote: > > > > > Hi All! > > > > > > @Maximilian Michels <m...@apache.org> has raised the question of Flink > > > version support in the operator before the last release. I would like to > > > open this discussion publicly so we can finalize this before the next > > > release. > > > > > > Background: > > > Currently the Flink Operator supports all Flink versions since Flink > > 1.13. > > > While this is great for the users, it introduces a lot of backward > > > compatibility related code in the operator logic and also adds > > considerable > > > time to the CI. We should strike a reasonable balance here that allows us > > > to move forward and eliminate some of this tech debt. > > > > > > In the current model it is also impossible to support all features for > > all > > > Flink versions which leads to some confusion over time. > > > > > > Proposal: > > > Since it's a key feature of the kubernetes operator to support several > > > versions at the same time, I propose to support the last 4 stable Flink > > > minor versions. Currently this would mean to support Flink 1.14-1.17 (and > > > drop 1.13 support). When Flink 1.18 is released we would drop 1.14 > > support > > > and so on. Given the Flink release cadence this means about 2 year > > support > > > for each Flink version. > > > > > > What do you think? > > > > > > Cheers, > > > Gyula > > > > >
