Thanks, Robert, for your hard work on this! It's fantastic to have the
process and tools in place to support the releases.
Beyond that, I’d also encourage the community to weigh in on features, bug
fixes, or any blockers leading up to the first release.
Yufei
On Mon, Sep 30, 2024 at 9:39 AM Robe
(Still catching up on emails after being a couple days off)
I've got some code as an experiment [1] to automate most of the work for
releases based on the Hugo-website branch. It's not quite in the state
to open a PR yet, and it's just one possible approach. What it can do so
far:
1. Draft a
+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
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 key points to
consider:
1. Since the endpoint is marked as deprecated, and most production
e
> If we remove the endpoint in Polaris, clients prior to that release will
have no mechanism for generating a token.
Missed to address this in my previous reply :)
Existing Java REST Catalog clients (based on Iceberg's impl.) will be able
to use bearer tokens and the Client Credentials OAuth2 Flo
> If we remove the endpoint in Polaris, clients prior to that release will
have no mechanism for generating a token.
The basic problem is that producing an auth token from the /token endpoint
in Polaris makes it assume the role of the Authorization Server according
to the OAth2 RFC [2].
Moreover,
That’s a good point.
I think we can keep the endpoint for 1.0 but already flag as deprecated.
Thoughts ?
Regards
JB
Le lun. 23 sept. 2024 à 21:05, Michael Collado a
écrit :
> +1 on Russell’s comment.
>
> Re: the OAuth endpoint, it seems to me that compatibility with Iceberg
> clients needs to
If we use 1.0-incubating it’s fine.
Ok for that :)
Regards
JB
Le lun. 23 sept. 2024 à 20:53, Russell Spitzer
a écrit :
> My only minor feedback is I'd prefer we do a first release as 1.0. I think
> there is an allergy to 0.1 software in production so I'd rather we just
> start at 1.
>
> On Mon
+1 on Russell’s comment.
Re: the OAuth endpoint, it seems to me that compatibility with Iceberg
clients needs to be considered. I think that prior to Iceberg 1.5 or so,
there was not support for an external oauth tokens endpoint. If we remove
the endpoint in Polaris, clients prior to that release
Good point, Russell! Starting with 1.0 makes sense to me.
Cheers,
Dmitri.
On Mon, Sep 23, 2024 at 2:54 PM Russell Spitzer
wrote:
> My only minor feedback is I'd prefer we do a first release as 1.0. I think
> there is an allergy to 0.1 software in production so I'd rather we just
> start at 1.
>
My only minor feedback is I'd prefer we do a first release as 1.0. I think
there is an allergy to 0.1 software in production so I'd rather we just
start at 1.
On Mon, Sep 23, 2024 at 1:50 PM Jean-Baptiste Onofré
wrote:
> Hi Dmitri
>
> It makes sense to me.
>
> Regards
> JB
>
> Le lun. 23 sept. 2
Hi Dmitri
It makes sense to me.
Regards
JB
Le lun. 23 sept. 2024 à 20:01, Dmitri Bourlatchkov
a écrit :
> From my POV, I'd propose to resolve the OAuth token endpoint concern [1]
> before the initial release.
>
> I guess it might be a rather big refactoring, but this issue is already
> general
>From my POV, I'd propose to resolve the OAuth token endpoint concern [1]
before the initial release.
I guess it might be a rather big refactoring, but this issue is already
generally accepted as a security concern in the Iceberg community, so I
think it would be preferable to resolve it before th
Hi folks,
As we know from experience, that the first release needs some careful
preparation steps, I would like to propose aiming for the Apache
Polaris release by the end of October (after CoC NA).
I propose to start from 0.1-incubating (currently we are building
999-SNAPSHOT :) ).
I already cre
18 matches
Mail list logo
