+1 on the "LTS + the two latest Flink releases" approach. This will ensure Iceberg releases match the officially supported Flink releases at release time. It's a compromise because Flink and Iceberg releases will never be aligned perfectly, but I think it is reasonable.
Long term, I wonder whether we can support more Flink versions in a more lightweight way, without copying all source files. In Apache Beam, for instance, we only copy API-incompatible files between Flink minor versions where the set of changes is usually very small. While this avoids copying the entire source code, it also makes reviewing much easier. I wonder, could we try the above approach for Flink 2.3 support? We would have a shared source folder for 2.x releases. For a concrete version, we inherit that code and only overlay any necessary changes. That way we should be able to support more Flink versions going forward. Cheers, Max On Thu, Aug 27, 2026 at 9:56 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 > >
