Hi All, I agree with Manu that keeping version overlap makes sense from a production perspective. I also support Max's suggestion of adopting the "LTS + two latest releases" approach, but I believe we shouldn't switch to it immediately.
Instead, we could announce in this release that we will adopt the "LTS + two latest releases" policy going forward. For the 1.12.0 release specifically, we could support 1.20 (LTS), 2.1, 2.2, and 2.3. Then, in the next Iceberg release (if Flink 2.4 is available), we can drop 2.1 and 2.2 and add 2.4. What do you think? Best, Talat On Thu, Aug 27, 2026 at 6:07 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi Peter, > > It looks good to me. > > Regards > JB > > On Thu, Aug 27, 2026 at 9:55 AM Péter Váry <[email protected]> > wrote: > > > > Hi Team, > > > > As Iceberg 1.12.0 is approaching, we need to finalize the Flink support > matrix. > > > > Based on the previous discussions and PRs, my takeaway is that the > community generally supports an "LTS + two latest Flink releases" policy: > > > > Iceberg 1.11.0: Flink 1.20, 2.0, 2.1 > > Iceberg 1.12.0: Flink 1.20, 2.2, 2.3 > > > > The main drawback is that there is no overlap between the Flink 2.x > versions, making independent Flink and Iceberg upgrades harder. While not > ideal, I think skipping any upgrades is worse. > > > > Unless there are strong objections, I'd like to propose that we adopt > this policy and implement the Flink upgrades so the Iceberg 1.12.0 release > can proceed. > > > > In the meantime, could someone prepare the upgrade PR? Following our > usual approach: > > > > Move Flink 2.1 code to 2.3. > > Remove Flink 2.0 support. > > Copy Flink 2.2 from Flink 2.3. > > Apply any required build and code fixes. > > > > Please speak up if you have concerns with this direction. > > > > Thanks, > > Peter > > > > >
