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
