Hi folks, Thanks for the honest feedback. I think it's best to not re-attempt the experience.
Thanks, Alex On Thu, May 28, 2026 at 4:00 PM Jean-Baptiste Onofré <[email protected]> wrote: > > 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 > >
