Hi Alex, First of all, thanks for driving the Iceberg 1.11 effort and for all the amazing work here. I think the ahead of time development helped Polaris stay proactive and gave us early visibility into important changes and compatibility issues.
That said, my preference for Iceberg 1.12 would be option 1, discontinue ahead of time development. >From my perspective, the biggest issue is the operational overhead it creates for both PR authors and reviewers. Cherry picks, repeated reviews, merge conflicts, and branch drift all add significant maintenance burden, especially when cherry-picks are not trivial, the ammount of time spent on authoring and reviewing are doubled. I think the cost is currently outweighing the benefits, especially as Polaris continues to grow and the codebase evolves more quickly. Thanks again for kicking off this discussion. Love to hear what others think. Yufei On Wed, May 27, 2026 at 6:44 AM Alexandre Dutra <[email protected]> wrote: > Hi all, > > Some time ago, we created the feature/iceberg-1.11 branch to stay > ahead of the curve with upcoming Iceberg 1.11 enhancements. It is now > an appropriate time to evaluate that experience and determine our > strategy for Iceberg 1.12. > > # What worked well > > - It enabled us to offer early support for functionalities such as > view registration and table registration with overwrite. > - We proactively identified breaking changes, such as the idempotency > key parameter, before they became critical. > > # What didn't go well > > - The process of cherry-picking commits from the feature branch into > main after the official Iceberg 1.11 release was inefficient: it > resulted in new PRs, redundant reviews and in some cases, the patches > didn't apply cleanly. > - Despite regular merges, the feature branch significantly drifted > from main. Specifically, the Ranger authorizer implementation caused > substantial rework for certain cherry-picks, some of which are still > being reviewed. > > So, what should we do for Iceberg 1.12? > > 1) Discontinue ahead-of-time development, it's a waste of time. > 2) Maintain our current approach without modification. > 3) Implement a different methodology (please provide details). > > I'm curious to have your thoughts on this. > > Thanks, > Alex >
