Hi Alex, I agree that it is very convenient to anticipate major changes, such as Iceberg updates, Ranger, or NoSQL, in dedicated branches.
However, I don't believe we need feature branches directly on the Polaris repository. It would be more efficient to use Pull Requests from contributor forks. On a related note, I also think contributors should avoid creating "personal" branches on the main Polaris repo (see https://github.com/apache/polaris/branches/active); using forks for PRs is a much cleaner and more effective approach. Regards, JB On Wed, May 27, 2026 at 3:44 PM 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 >
