Hi Dmitri, I agree the risk here is low, since Polaris does not issue authorization requests for these operations today.
I do think it helps to separate three different contracts in the discussion related to compatibility: 1. SPIs, such as PolarisAuthorizer 2. public enum sets / authorization vocabulary, such as PolarisAuthorizableOperation 3. external integration contracts, such as the OPA request schema I think grounding the discussion in those contracts, and in how they relate to each other, will help us define the right compatibility expectations at the right boundaries. As a starting point, for SPI evolution, I think some amount of change is expected, especially at this stage of the project, at least for the authorization SPI. The impact of an incompatible change is usually fairly visible at upgrade time, for example when an integration no longer compiles. For external request contracts, I think the compatibility bar should be higher, since those changes can affect deployed integrations more indirectly. So for this specific change, removing unused PolarisAuthorizableOperation values seems reasonable to me. More generally, though, I think the project could more explicitly define how we want to handle backward compatibility for each of these contracts. +1 on reviving the broader SPI discussion. I see that EJ picked up that issue already, I'm looking forward the discussions! Cheers, Sung On 2026/03/13 20:31:14 Dmitri Bourlatchkov wrote: > Hi All, > > Two PR have been proposed that remove unused values from > PolarisAuthorizableOperation: [3991], [3994]. > > EJ, made a point that these changes affect the Authorizer SPI and general > Authorization vocabulary in Polaris, and that there might be > compatibility concerns. > > While I agree that these points have merit in general, as far as Polaris is > concerned I'd like to offer a different perspective. > > At this point, Polaris as a project is still in very early stages of code > maturity. Refractorings are very common and the java SPI / API surface is > subject to changes in pretty much every feature proposal. Moreover, we do > not yet have a formal SPI definition. Consequently, the standing Polaris > Evolution doc [1] informs users that java code changes are to be expected > at any time. Only the REST API is covered by SemVer "major change" > principles [2]. > > Re: authZ compatibility: Operation names indeed make their way into OPA > requests (as an example). However, given that the removed op names are > never requested by Polaris for authorization, there is not reason for any > specific implementation to rely on them. > > If some authorizer policies do refer to the removed op names somewhere, > those references by nature are "soft links" and will not break after > removing the corresponding enum values from Polaris core. > > Re: authZ vocabulary: The unused enum values have no real meaning right > now. Documentation does not cover them and there is no code that could be > used to deduce the meaning. Enum names themselves are probably too weak to > define any particular behaviours expected of authorizer implementations. > > Moreover, the removed op names appear to be very specific to the Polaris > "native" RBAC model, so "external" authorizer (e.g. OPA, Ranger) probably > do not need any special handling those operations even if Polaris used them > in Authorizer calls. > > Other opinions are welcome. > > Should new use cases arise for the removed entities, we would restore them, > of course. > > [1] https://polaris.apache.org/in-dev/unreleased/evolution/ > > [2] https://semver.org/ > > [3991] https://github.com/apache/polaris/pull/3991 > > [3994] https://github.com/apache/polaris/pull/3994 > > Cheers, > Dmitri. >
