+1 to the above. I think maintaining backwards compatibility is paramount.
I would actually like to see us somewhat couple our release cycle with
Iceberg's as the spec lives there and Polaris's clients will be adhering to
that spec. When Iceberg goes to 2.0, perhaps Polaris should go to 2.0. I
wou
I intended to write "marking it deprecated", but... fat-fingers :)
The token endpoint is deprecated, but existing Iceberg clients rely on its
existence. Anyone on a release older than a few months will be unable to
authenticate to Polaris without that endpoint. I think maintaining
compatibility wi
Sorry, I'm not sure I follow the deprecation argument.
The token endpoint is already deprecated in the Iceberg REST Catalog spec.
Polaris cannot "make" it deprecated as the spec is owned by Iceberg.
Polaris essentially implements a deprecated API.
Why would we want to implement a deprecated (an
Agree with Yufei 100%. Making it as deprecated, as the Iceberg spec does,
makes total sense. We should remove it when Iceberg 2.0 is released.
Mike
On Tue, Sep 24, 2024 at 4:46 AM Jean-Baptiste Onofré
wrote:
> Hi Yufei
>
> Yes agree.
>
> Regards
> JB
>
> Le mar. 24 sept. 2024 à 01:40, Yufei Gu
Hi Yufei
Yes agree.
Regards
JB
Le mar. 24 sept. 2024 à 01:40, Yufei Gu a écrit :
> For the token endpoint, I recommend we stay consistent with the Iceberg
> REST spec by marking it as deprecated and aligning its removal with the
> same timeline as outlined in the Iceberg spec. Here are a few k
