Hi Manu, I just saw your message.
>1. Have we ever upgraded two versions simultaneously before? Does this mean >that what's been developed for Flink 2.0 and 2.1 will continue to work for 2.2 >and 2.3? Generally, Flink application upgrades are supported between minor versions, but I understand the argument for keeping at least one version overlap. It potentially makes for a better Iceberg upgrade story for users, which could help Iceberg adoption. That said, we are keeping Flink 1.20 as the LTS version. The real issue with the overlap is that it assumes users upgrade Iceberg and Flink on a regular basis, which from my experience isn't the case. To make up for that, we would end up having to support virtually all Flink versions. Overall, I favor keeping things simple and manageable. Skipping a minor version in the upgrade path isn't an issue. > 2. Since Iceberg 1.12.0 release is approaching, is this the right time to > upgrade? We won't have much time left to verify. The actual set of changes are very small in this case since we're upgrading a minor version. Here's the upgrade PR: https://github.com/apache/iceberg/pull/17845 -Max PS: To my earlier argument on a different way to support Flink versions, I think it is better to defer this decision until the 1.12.0 release. On Thu, Aug 27, 2026 at 11:16 AM Maximilian Michels <[email protected]> wrote: > > +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 > > > >
