In the meantime I have merged https://github.com/apache/iceberg/pull/17849, as the general sentiment is that we would like to support Flink 2.3 and 2.2. We might still decide to remove Flink 2.1 support, but that's an easier PR if we decide so.
> There is no inherent issue with skipping an Iceberg or Flink version. I think it is better to have the possibility to upgrade Iceberg and Flink independently, so I would keep the Flink 2.1 for now. Thanks, Peter Maximilian Michels <[email protected]> ezt írta (időpont: 2026. aug. 28., P, 13:57): > Hi Talat, > > Thanks for looking into this! I understand the sentiment to retain as much > Flink version support as possible. But we never had a consistent version > support policy. I don’t think we need to announce one ahead of the release. > > The upgrade cadence in organizations for both Flink and Iceberg vary > wildly. Its rare that they move sequentially through both Iceberg and Flink > versions. There is no inherent issue with skipping an Iceberg or Flink > version. > > LTS + two release versions matches the Flink upstream support and keeps > things manageable. > > Maybe others can chime in as well. > > Thanks, > Max > > > Talat Uyarer via dev <[email protected]> schrieb am Do. 27. Aug. > 2026 um 20:06: > >> Please do not misunderstand me; I had a little bit of time, so I created >> a pull request to unblock the release candidate as I suggested. >> >> https://github.com/apache/iceberg/pull/17849 >> >> This does not prevent Max's pull request from proceeding. I am perfectly >> fine if Max updates his pull request to reflect the latest decision. >> >> On Thu, Aug 27, 2026, 8:51 AM Péter Váry <[email protected]> >> wrote: >> >>> @[email protected] <[email protected]>: How hard would be to >>> update the PR to follow Talat's suggestion? >>> >>> This seems like a good compromise. We could enable a seamless upgrade >>> path and we could limit the development effort by removing the Flink >>> version immediately after cutting the release branch. >>> >> >>> Talat Uyarer via dev <[email protected]> ezt írta (időpont: 2026. >>> aug. 27., Cs, 17:37): >>> >>>> 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 >>>>> > >>>>> > >>>>> >>>>
