Hi Eric, This situation here is that some code moves from a private downstream project to Polaris. Some of the related config names are already in use downstream.
Cheers, Dmitri. On Thu, Nov 27, 2025 at 7:35 PM Eric Maynard <[email protected]> wrote: > I read through the PR, but I’m a little confused what the dependency in > question is here. Surely, the project should be mindful not to break > downstream dependencies of Polaris. But it sounds like the contention here > is around a dependency on unmerged code? > > If this is the case, that deployment is not depending on Polaris. In my > view if it depends on particular configs not present in OSS Polaris, > it would be best served by taking advantage of some of the mechanisms > available for adding custom configs on top of the ones in OSS Polaris. > > —EM > > On Thu, Nov 27, 2025 at 10:53 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi All, > > > > This discussion stems from PR [3135], where having particular config > names > > was flagged as a concern [1]. > > > > While I agree that aligning configuration names across all Polaris code > > modules is a worthy goal, in this particular case it is complicated by > > downstream dependencies that already exist on those config names. > > > > The NoSQL code contributed in this PR is already in use in private > > environments. At the same time it is being contributed to Polaris in the > > hole that it would be beneficial to a wide community. > > > > Making the requested config changes up front would complicate > > re-integration of the contributed code from Polaris `main` into existing > > downstream projects. > > > > Therefore, I ask the community to allow the existing config names to be > > merged. > > > > If there are strong concerns about the existing config names, I propose > to > > open GH issues for them and address later when backward compatibility can > > be handled in OSS code for all use cases. This can probably be done after > > some reasonable delay to allow us to first re-integrate the code from > > `main` downstream. > > > > Note that addressing config renames with backward compatibility directly > in > > [3135] would complicate the code and make reviewing it harder. The > current > > PR reflects the code that has already been put to practice. > > > > We have an existing situation where a downstream project's requirements > for > > keeping `polaris-code` java compatibility at version 11 are respected [2] > > despite having no reasons for holding that module's java version back > from > > the perspective of binary Polaris Server distributions. > > > > In general, I believe it is important for the success of the project to > > take downstream builds into consideration as well as users of the binary > > distribution. > > > > Please share your thoughts on this matter. > > > > [1] https://github.com/apache/polaris/pull/3135#discussion_r2558515915 > > > > [2] > > > > > https://github.com/apache/polaris/discussions/100#discussioncomment-10267097 > > > > [3135] https://github.com/apache/polaris/pull/3135 > > > > Thanks, > > Dmitri. > > >
