Re: [VOTE] Change Create APIs to Return Newly-Created Objects

+1 Thanks for working on this, Adnan! It's also nice to mention it in the changelog as Dmitri pointed out. Yufei On Fri, Sep 19, 2025 at 8:58 AM Dmitri Bourlatchkov wrote: > +0 As I commented in GH, code changes LGTM (as of commit f0b6896), but I > believe we ought to mention the change in API

Re: [DISCUSS] Always obtaining AccessConfig

Hi Dimitri, Thanks for the discussion thread to bring awareness. The change in 2615 makes sense to me. Yufei On Fri, Sep 19, 2025 at 8:26 AM Dmitri Bourlatchkov wrote: > Hi All, > > In order to support non-AWS S3 implementation better I propose [2615] to > obtain AccessConfig at the REST API l

Re: [DISCUSS] - When to remove EclipseLink?

+1 on removing it. Given Polaris’ monthly release cadence, it seems fine to wait two (remove in 1.3) or three (remove in 1.4) more releases. https://github.com/apache/polaris-tools/tree/main/polaris-synchronizer can migrate principals, but doesn't support policies. I’m not sure it’s worth buildin

Re: [DISCUSS] Add Idempotency-Key to Polaris REST mutations

erful, > especially considering Polaris Servers in a distributed environment. > > To put it another way, I believe implementing the "idempotency" proposal on > top of the "tasks" proposal is going to be quite easy (if not trivial). > > [1] https://lists.apa

Re: DISCUSS: 1.2 release

Thanks Prashant for volunteering. It's the right time to get started with the 1.2 release. I'd suggest setting ETA to the end of October, given the 1.1 is not out yet, and it's September 15th already. Yufei On Mon, Sep 15, 2025 at 1:48 PM Prashant Singh wrote: > Hey All, > > Thank you everyone

Re: [PROPOSAL] Add Data Lake operational metrics to Polaris

y, etc. This reduces the overhead of the Node Exporter. And I think > we could start with a similar approach for Polaris. > > -- > > Pierre > > > On Sat, Sep 6, 2025 at 1:46 AM Yufei Gu wrote: > > > Thanks, Pierre, for the proposal. I’m excited about the potent

Re: [DISCUSS] Add Idempotency-Key to Polaris REST mutations

Hi Dimitri, The idempotency key is mainly to reduce the chance of inconsistencies of table commit. Here is a typical scenario: A commit succeeds but the client misses the response (due to timeout, restart, etc.), client retries and hits 409 Conflict, then mistakenly treats this as a failed commit

Re: [EXTERNAL]Re: Aurora postgres passwordless DB

> > Fabio > > From: Yufei Gu > Date: Tuesday, 9 September 2025 at 23:00 > To: dev@polaris.apache.org > Subject: Re: [EXTERNAL]Re: Aurora postgres passwordless DB > > Hi Rizzo, > > Did you check the aws-advanced-jdbc-wrapper, > https://github.com/aws/aws-advanced-jd

Re: [EXTERNAL]Re: Aurora postgres passwordless DB

Hi Rizzo, Did you check the aws-advanced-jdbc-wrapper, https://github.com/aws/aws-advanced-jdbc-wrapper? It provides a bunch of examples, including things like "Using the AWS IAM Authentication Plugin with DataSource", as well as support for HikariCP, c3p0, Spring. Unfortunately, I could find Quar

Re: Proposed Public OpenAPI Changes

Thanks for the proposal, Adnan. Returning representations from the create endpoints makes sense to me and will reduce a follow-up GET in most clients. For addGrantToCatalogRole, the grant itself is more a relationship between entities than entity itself. I understand it returns 201(Created) now,

Re: [VOTE] Release Apache Polaris 1.1.0-incubating (rc0)

+1 as we don’t consider 2501 as a blocker Yufei On Fri, Sep 5, 2025 at 22:56 Jean-Baptiste Onofré wrote: > +1 (binding) > > Regards > JB > > On Mon, Sep 1, 2025 at 5:34 AM Jean-Baptiste Onofré > wrote: > > > > Hi everyone, > > > > I propose that we release the following RC as the official >

Re: [PROPOSAL] Add Data Lake operational metrics to Polaris

Thanks, Pierre, for the proposal. I’m excited about the potential of serving these metrics via Polaris. They would be highly valuable for multiple use cases, including UI integration, TMS (deciding when and how to compact a table), monitoring, cost awareness (through table size trending), and query

Re: Re: [DISCUSS] Add JDBC Metastore table index

Hi Artur, thanks for sharing the experiment results. Do we have any data on the write side? The entity table holds almost everything in Polaris. We cannot ignore the write side impact. Also if the read perf doesn't improve a lot, we may leave the index as is. We can document how the extra index hel

Re: [VOTE] Release Apache Polaris 1.1.0-incubating (rc0)

Hi Pierre, I can confirm I'm using MacOS + Docker desktop. I will need a bit of time to set up the Podman desktop due to the license limitations. Let's have more discussion on the issue Russell created, https://github.com/apache/polaris/issues/2501. Yufei On Thu, Sep 4, 2025 at 8:56 AM Russell Sp

Re: [PROPOSAL] Polaris onboarding/user experience and Polaris UI

Awesome, thanks for the update! On Thu, Sep 4, 2025 at 01:27 Jean-Baptiste Onofré wrote: > Hi folks, > > FYI, I'm resuming the work on the UI, I have the first components > working with the backend. > I will probably submit a draft PR on polaris-tools as a discussion base. > > Stay tuned ;) > >

Re: [PROPOSAL] Polaris Table Source and Common Table API

Thanks JB for scheduling a meeting. CoC started on the 11th. Multiple Polaris talks will happen in that morning. Can we shift to another day? Yufei On Thu, Sep 4, 2025 at 9:18 AM Jean-Baptiste Onofré wrote: > Hi folks, > > First of all, thanks everyone for your highly valuable comments and > q

Re: [VOTE] Release Apache Polaris 1.1.0-incubating (rc0)

Verified Sigs and Checksums Checked the Helm Chart release, the index looks good. Checked the binary distribution The build failed with the similar issue: > Task :polaris-runtime-service:intTest RestCatalogKeycloakFileIT > initializationError FAILED org.junit.jupiter.api.extension.Parameter

Re: Incubator report for Sep 25

Hi JB, Thanks for the report. LGTM. Yufei On Tue, Sep 2, 2025 at 2:46 PM Dmitri Bourlatchkov wrote: > Hi JB, > > The report looks good to me. Thanks for putting it together! > > Cheers, > Dmitri. > > On Mon, Sep 1, 2025 at 8:58 AM Jean-Baptiste Onofré > wrote: > > > Hi folks, > > > > I drafte

Re: [DISCUSS] Add a plugin point for extracting storage config from entities

Hi Dimitri, > add another integration point that would handle the construction of PolarisStorageConfigurationInfo and work in conjunction with PolarisStorageIntegrationProvider Could you share more details about it? Or we can just review the PR. Yufei On Wed, Aug 20, 2025 at 10:59 PM Jean-Bapt

Re: [DISCUSS] Require changelog updates within applicable PR

I'm not a big fan of it, as I'm not sure how we execute it effectively. 1. How do we define "applicable" PR? 2. What if they are reverted? 3. What should go to changelog for each individual PR when a feature is splitted to multiple PRs? I'd suggest that if we really want it, we need a clear defini

Re: [RELEASE] 1.1.0-incubating release preparation

> > wrote: > > > > > > I just opened https://github.com/apache/polaris/pull/2406 with the > list > > of > > > new features that were added in main since the 1.0.x release branch was > > > cut. Would it be possible to get a review to ensure I did

Re: [DISCUSS] Labels for GitHub issues + PRs

The blocker label is a tool to make our life easier. For example, https://github.com/apache/polaris/pull/2420 is a PR to fix the broken main, which is definitely a 1.1.0 blocker given the 1.1 branch wasn't cut yet. Labeling it makes total sense to me. Release manager or anyone who cares about the r

Re: [DISCUSS] Labels for GitHub issues + PRs

Why do we remove the 1.1.0-blocker? Yufei On Wed, Aug 20, 2025 at 11:15 PM Robert Stupp wrote: > SGTM > > I'm fine with temporary labels. > > If noone objects, I'd go ahead and remove the unused labels plus these: > - 1.0-blocker > - 1.1.0-blocker > - 1.0.0 bug bash > - IdentityRoleFederation

Re: Re: [DISCUSS] S3 Credential vending without STS

3V4RestSignerClient doesn't handle batch signing. > > How do you envision batch signing? > > > > > Should we add rate limiting to avoid endpoint abuse? > > > > Polaris is already rate-limited, is there anything else you need? > > > > > How do clients l

Re: [RELEASE] 1.1.0-incubating release preparation

Hi JB, Make sense to move some enhancement and proposals to 1.2. e.g., Support for OpenLineage. Some of 1.1 items have been done, we could close them. I haved moved a few of them to 1.2. Meanwhile, can we have a list of new things shipped with 1.1.0? Yufei On Tue, Aug 19, 2025 at 2:55 PM Dmitr

Re: Re: [DISCUSS] S3 Credential vending without STS

t; Dmitri. > > > > On Mon, Aug 18, 2025 at 11:54 AM Alexandre Dutra > wrote: > > > > > Hi Yufei, > > > > > > Yes, sure! There you go: > > > > > > > > > > https://docs.google.com/document/d/1ygdia7u4bUHUt6n8XhZo48aKoIyy

Re: [DISCUSSION] Integrations points in Polaris

Looks like we got a consensus to confine SPI in certain modules. Here are a few candidates: 1. polaris-core 2. All modules under /api 3. polaris-runtime-service, this module is a bit controversial, as it holds a lot of implementation as well as interfaces. Options would be 1. to move interfaces to

Re: [DISCUSSION] Integrations points in Polaris

Thanks Dennis for listing these SPIs. To make it easy for developer to understand, I think we have multiple options 1. Annotation-based approach, Apache Spark adopts it, e.g., @Stable, @@Experimental. It is fine-grained, but it brings a lot of maintenance costs. For example, which interfaces shoul

Re: Re: [DISCUSS] S3 Credential vending without STS

ssie instances (pods) > > > accessing the same backend. > > > > > > We can certainly contribute this functionality, which already works in > > > many production environments, to Polaris. > > > > > > Robert > > > > &

Re: Removal of CallContext.copy()

sk is > > > > one of possible requests. As such it has well defined parameters and > > > > begin/end boundaries. Any context that a task needs should naturally > flow > > > > from its parameters (which define the job to perform). > > > > > > > > Ultim

Re: Removal of CallContext.copy()

gt; yet. > > --EM > > On Wed, Aug 13, 2025 at 12:18 AM Robert Stupp wrote: > > > Thanks for the reply Yufei, but the intent of all tasks-proposals is > > to be able to execute tasks on _any_ node. Are you suggesting making > > (Polaris)CallContext serializable? &g

Re: Removal of CallContext.copy()

> To still let TaskExecutorImpl making "safe clones", a functionality to get (fresh) instances of RealmContext is required. To enable this, the RealmContextResolver has been enhanced with "RealmContext lookups" by realm-ID. That in turn led to splitting the HTTP/REST-to-realm-context resolution int

Re: [DISCUSS] Apache Polaris (incubating) 1.1.0 release mid August ?

yet. It would be good if I could either perform the > release (or shadow the release manager). So if nobody has volunteered > yet, I would like to volunteer for the 1.1.0 release manager role. > > Wdyt? > -- > > Pierre > > > On Tue, Aug 5, 2025 at 1:37 AM Yufei Gu wrote

Re: [MEETUPS] Proposed Seattle Meetup

Danica, Thanks for organizing it. +1 to the meetup. Also +1 on having a guideline similar to what the Iceberg community has. Yufei On Wed, Aug 6, 2025 at 4:47 PM Danica Fine wrote: > Hi all, > > I'm kicking off this thread to get approval to host the first ever Apache > Polaris-specific meetu

Re: Schema setup in admin tool and server

reserve data integrity. I'd prefer > that we start with something simple (the schema either exists or > doesn't exist at all). > > Can we maybe start to transform the above ideas into actionable items? > > Thanks, > Alex > > > On Mon, Aug 4, 2025 at 10:58 PM Yu

Re: Re: [DISCUSS] S3 Credential vending without STS

; > > Another option is still to configure the object storage credentials at > > the clients. It's not great, but it's still an option. Admins can give > > each client individual credentials to reduce potential risks, being > > able to revoke access for individual cl

Re: [DISCUSS] Apache Polaris (incubating) 1.1.0 release mid August ?

ssion about Generic Tables (about experimental yes or no) > is independent to the release cycle. > > Anything blocker (break build or regression) is a blocker for release, > and definitely must be included in the next release. > The rest is best-effort. > > Regards &g

Re: Schema setup in admin tool and server

> In practice though it is possible that different realms get bootstrapped with different database schemas and I think we should try to make the service resilient to situations like this +1 on this. Each realm could have its own schema, or even different Postgres server. A bit more context on it,

Re: [DISCUSS] Adding endpointInternal to AwsStorageConfigInfo

> Polaris puts "s3.endpoint" into loadTable responses when credential > vending > > > is enabled. > > > So, yes, both settings are needed, but only in complex deployment > cases. > > > > > > If the same endpoint works for both the engine

Re: [DISCUSS] Adding endpointInternal to AwsStorageConfigInfo

erver? > Cheers, > Dmitri. > > > > On Thu, Jul 31, 2025 at 5:59 PM Yufei Gu wrote: > > > Thanks for the explanation. Two questions: > > 1. Should the public endpoint used by engines still work with Polaris > even > > if it co-locates with MinIO server? >

Re: [DISCUSS] Adding endpointInternal to AwsStorageConfigInfo

erent network. This is very > high-level, of course, since the deployment choices are largely driven by > specific users' needs. The proposed "endpointInternal" config entry merely > expands deployment options that users can choose from. > > Cheers, > Dmi

Re: [PROPOSAL] Asynchronous & Reliable Tasks

Thanks for the async task proposal. I think it's the right direction for async light tasks. Meanwhile, we will still need other models: 1. A scalable way to execute synchronous tasks 2. A scalable way to execute heavy async tasks, e.g., table maintenance tasks. The delegation service[1] is a good

Re: [DISCUSS] Adding endpointInternal to AwsStorageConfigInfo

Hi Dimtri, That generally makes sense to me. For awareness, could you elaborate a bit on how the Polaris server and query engines (like Spark, Trino, etc.) might access the same object storage (e.g., MinIO) via different DNS endpoints? Yufei On Thu, Jul 31, 2025 at 4:36 AM Alexandre Dutra wrot

Re: [DISCUSS] Merge polaris-service-common into polaris-runtime-service

+1. Thanks Alex for driving this. Other than the benefits discussed like removing the duplicated config classes like `QuarkusStorageCredentialCacheConfig`, or removing `.quarkus.` in the package name, we can finally put classes like S3AccessConfig and StsClientsPool into the right package. Yufei

Re: Release automation scripts

Thanks Pierre for working on this. It's great start point to automate release workflow. Yufei On Tue, Jul 22, 2025 at 10:17 AM Pierre Laporte wrote: > Hello folks > > I just published a new PR (#2156) > so that Polaris has > semi-automated releases

Re: [DISCUSS] S3 Credential vending without STS

Thanks for raising this, Dmitri! For non-STS use cases, some users may be more comfortable without credential vending. They could configure the storage credentials at the engines side. Can we first confirm that vending raw credentials are really users asking for? If that's the case, raw credentia

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

> > > > consider > > > > > > > > > >> >> > > doing > > > > > > > > > >> >> > > > > nightly build > > > > > > > > > >> >> > > > > releases in the short term? > > > > > > > > >

Re: [VOTE] Release Apache Polaris 1.0.1-incubating (RC0)

Thanks JB! +1 Verified the Helm Chart with Postgres setting using the following command: export POSTGRES_PASSWORD='abcedf' helm install postgres oci://registry-1.docker.io/bitnamicharts/postgresql \ -n polaris \ --set auth.postgresPassword=$POSTGRES_PASSWORD \ --set auth.username=polaris \

Re: [DISCUSS] Apache Polaris (incubating) 1.1.0 release mid August ?

gt;> > instead list what we want by priority: as soon as it’s ready we > ship > > > it in > > > >> > the month release. > > > >> > > > > >> > With this approach, and as we will have a release every month, I’m > > > not sure >

Re: [DISCUSS] Apache Polaris (incubating) 1.1.0 release mid August ?

as I can tell. It may be worth having a separate discussion > thread for this. > > +1 to a separate helm repo (I believe this was discussed in another thread > too). > > +1 to include CLI into the binary bundle. > > Cheers, > Dmitri. > > On Mon, Jul 28, 2025

Re: [DISCUSS] Apache Polaris (incubating) 1.1.0 release mid August ?

The timeline LGTM! We’ll need to align on the scope. In addition to several ongoing features that should be ready by then, like MinIO support and KMS support (PR #1424). There are a few key items(not a complete list) that need discussion: - Generic Table & Catalog Federation Status: We need to

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

The use case of passing secrets via REST is definitely valid, and this use case is not the only one we should be considering. Other concrete scenarios include: 1. Catalog federation, where Polaris needs to store credentials to connect to remote catalogs (e.g., Hive, Glue, Unity Catalog).

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

lobal source distribution > including Helm sources). > So, I propose to include a source tar gradle task in Helm chart (with > signing and checksum). If we do that, no problem. I can take a crack > on this :) > > Regards > JB > > On Sat, Jul 12, 2025 at 1:30 AM Yufei Gu

[Discussion] Decoupling Helm chart releases (+ nightly build proposal)

Hi everyone, While testing the freshly-minted 1.0.0-incubating release, we noticed something odd: the Polaris release has relational-jdbc persistence, yet the Helm chart only understands the legacy eclipselink. Here is the issue: https://github.com/apache/polaris/issues/2030. We previously made t

Re: Any volunteers for the next Polaris Release Manager?

Thanks, JB, for volunteering to be the 1.1 release manager! Yufei On Fri, Jul 11, 2025 at 9:32 AM Jean-Baptiste Onofré wrote: > Hey > > In our path to get semi-automatic and regular release (I propose to have > monthly release), I’m happy to help on 1.1 with a focus on max automatic > process.

Re: [Discuss] Default commit message during merge/squash

It's a valid concern if that description doesn't match with the commit. But I'm fine with it as long as we can modify the description at the merging time. Yufei On Thu, Jul 10, 2025 at 12:07 PM Eric Maynard wrote: > If there are things missing from Renovate that mean we can't configure the > c

Re: [DISCUSS] Adding pathStyleAccess to AwsStorageConfigInfo

Thanks for working on this. Makes sense to add `pathStyleAccess`. Yufei On Wed, Jul 9, 2025 at 12:34 AM Omar Al-Safi wrote: > Hi Dmitri, > > +1, personally I don't see any harm to add, plus besides supporting > S3-compatible storages, this allows supporting legacy s3 buckets that still > use p

Re: [DISCUSS] Hive Catalog federation in Polaris

, and likely can Polaris itself authorize > > itself using OAuth. > > > > I strongly object to depending even more on Hadoop for the reasons > > outlined earlier. I also strongly object to adding Kerberos to > > Polaris. > > > > BTW: Hadoop is not

[ANNOUNCE] Apache Polaris 1.0.0-incubating

The Apache Polaris team is pleased to announce Apache Polaris 1.0.0-incubating. Apache Polaris is an open-source, fully-featured catalog for Apache Iceberg™. It implements Iceberg's REST API, enabling seamless multi-engine interoperability across a wide range of platforms, including Apache Doris™,

Re: [DISCUSS] Prepare for 1.0 Release

Hi everyone, Please take 5 minutes to check the 1.0.0 release notes: https://docs.google.com/document/d/1JDVdQraoEhOIv7agy7WzIuBQdW0_16jW-DBrnanuW7A/edit?tab=t.0. We will publish it right after 1.0.0 was done. Yufei On Thu, Jun 26, 2025 at 10:31 AM Yufei Gu wrote: > Thanks for the validat

Re: [DISCUSS] Hive Catalog federation in Polaris

HMS integration is a key step toward one of Polaris’s critical missions: helping users move off HMS. It brings clear value by aligning with our long-term direction. I’m not too concerned about hive.xml, most of its configurations can be dynamically injected at runtime. The real challenge lies in K

Re: Remove k8s reference for kind

+1 on picking one, instead of having both. I don't have any preference though. Yufei On Mon, Jul 7, 2025 at 1:37 PM Dmitri Bourlatchkov wrote: > My personal preference is minikube. > > Cheers, > Dmitri. > > On Sat, Jul 5, 2025 at 8:22 PM Yong Zheng wrote: > > > Hello, > > > > Currently, we pr

[RESULT] [VOTE] Release Apache Polaris 1.0.0-incubating (RC6)

, 2025 at 11:38 AM Yufei Gu wrote: > Hi Dongjoon, JB, added the following additional files. Thanks Dongjoon for > sharing the point that the ASF INFRA team may or may not admit *.prov files > for signatures and checksums. This is an extra step to make sure the > release can pass. We d

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC6)

t 7:27 AM Robert Stupp wrote: > > > > > > > >> I haven't checked the release yet due to other things on my plate. > > > >> > > > >> With PR #1991 (Add polaris-spark-bundle project to help packing and > > > >> publish the Spark

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC6)

> > -- LICENSE and NOTICE look good > > > > -- Can start Polaris server from the binary distribution > > > > - Helm Chart Package > > > > -- incubating is in the version > > > > -- DISCLAIMER is present > > > > -- LICENSE and NOT

Re: [VOTE] Change apache/polaris CI Settings to only require approval for new contributors

+1, thanks for doing this, Ajantha! Yufei On Thu, Jul 3, 2025 at 6:12 AM Dmitri Bourlatchkov wrote: > +1 > > Cheers, > Dmitri. > > On Thu, Jul 3, 2025 at 1:32 AM Ajantha Bhat wrote: > > > Hello, everyone. > > I'm starting this thread to discuss the possibility of changing the CI > > settings f

[VOTE] Release Apache Polaris 1.0.0-incubating (RC6)

Hi everyone, I propose that we release the following RC as the official Apache Polaris 1.0.0-incubating release. This corresponds to the tag: apache-polaris-1.0.0-incubating-rc6 * https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc6 * https://github.com/apache/polaris/tre

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC5)

CENSE and NOTICE look good > >> > -- Can start Polaris server from the binary distribution > >> > - Helm Chart Package > >> > -- incubating is in the version > >> > -- DISCLAIMER is present > >> > -- LICENSE and NOTICE are good > >&

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC5)

kages and --jars options, tested > operations: > 1) create/insert values for both delta and iceberg tables > 2) create/drop namespaces > 3) create/drop iceberg and delta tables > > Things turned out to work accordingly. > > Best Regards, > Yun > > On Mon, Jun 30,

[VOTE] Release Apache Polaris 1.0.0-incubating (RC5)

Hi everyone, I propose that we release the following RC as the official Apache Polaris 1.0.0-incubating release. This corresponds to the tag: apache-polaris-1.0.0-incubating-rc5 * https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc5 * https://github.com/apache/polaris/tre

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC4)

artifacthub.io/changes: | > > > - description: Add extra secret annotations to most secrets > > > kind: added > > > links: > > > - name: '#48890' > > > url: https://github.com/apache/airflow/pull/48890 > > &

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC4)

cubating is in the name > -- LICENSE is missing OpenHFT: OpenHFT is shaded in Parquet, so should > be documented in LICENSE. OpenHFT (Java Lang) is using Apache license > (no NOTICE) (https://github.com/OpenHFT/Java-Lang/tree/master). Sorry > I missed that before. > > I will sync wit

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC4)

> > Le sam. 28 juin 2025 à 07:41, Yufei Gu a écrit : > > > Hi JB, Helm Chart has its own format called *.tgz.prov file, which > includes > > both checksum and signature, which you can find here, > > > > > https://dist.apache.org/repos/dist/dev/incubator/pol

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC4)

ed on dist repo) have to be > signed and checksum has to be provided, else the release is "invalid". > > Thanks, > Regards > JB > > On Sat, Jun 28, 2025 at 1:34 AM Yufei Gu wrote: > > > > Hi everyone, > > > > I propose that we release the foll

Re: AWS S3 KMS support in Polaris

the PR > <https://github.com/apache/polaris/pull/1424> when you get some time? > > Thanks, > Ashok > > On Thu, May 29, 2025 at 12:12 PM Ashok Borra > wrote: > >> +Raajan Ashish Pal >> >> On Thu, May 29, 2025 at 4:33 AM Yufei Gu wrote: >> >>> Hi

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC3)

; Dmitri. > > On Fri, Jun 27, 2025 at 3:09 PM Yufei Gu wrote: > > > Hi everyone, > > > > I propose that we release the following RC as the official Apache Polaris > > 1.0.0-incubating release. > > > > This corresponds to the tag: apache-polaris-1.0.0

[VOTE] Release Apache Polaris 1.0.0-incubating (RC4)

Hi everyone, I propose that we release the following RC as the official Apache Polaris 1.0.0-incubating release. This corresponds to the tag: apache-polaris-1.0.0-incubating-rc4 * https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc4 * https://github.com/apache/polaris/tre

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC3)

i, Jun 27, 2025 at 12:09 PM Yufei Gu wrote: > Hi everyone, > > I propose that we release the following RC as the official Apache Polaris > 1.0.0-incubating release. > > This corresponds to the tag: apache-polaris-1.0.0-incubating-rc3 > * > https://github.com/apache/polaris/

[VOTE] Release Apache Polaris 1.0.0-incubating (RC3)

Hi everyone, I propose that we release the following RC as the official Apache Polaris 1.0.0-incubating release. This corresponds to the tag: apache-polaris-1.0.0-incubating-rc3 * https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc3 * https://github.com/apache/polaris/tre

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC2)

NF/LICENSE.md > 26686 Fri Feb 01 00:00:00 EST 1980 LICENSE > > I suppose none of them should be there - preempted by our binary LICENSE. > > This is just a bit of input for > https://github.com/apache/polaris/pull/1950 > > Cheers, > Dmitri. > > > On Wed, Jun

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC2)

n't able to get the Shadow Jar to do it with built in functionality > so > > I brute forced it. If someone has a better approach I would suggest doing > > it as a followup unless there is time to do it rapidly. > > > > On Thu, Jun 26, 2025 at 1:57 PM Yufei Gu wro

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC2)

7d48796694-f2hv2 1/1 Running 0 73s I'm new to Helm Chart. It seems to work well for me, but let me know if you have any feedbacks Yufei On Thu, Jun 26, 2025 at 11:02 AM Yufei Gu wrote: > Per our discussion during the community sync-up, we’ll continue verifying > RC2

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC2)

includes the fix. To streamline the process and save time, we’ll aim for a quick, amended vote on RC3. In case of other issues found, we will go through the normal process for RC3. Yufei On Wed, Jun 25, 2025 at 8:02 PM Yufei Gu wrote: > Hi everyone, > > I propose that we release the follow

Re: [DISCUSS] Prepare for 1.0 Release

m/apache/polaris/pull/1945 > > Cheers, > Dmitri. > > On Wed, Jun 25, 2025 at 6:39 PM Yufei Gu wrote: > > > Agreed! We also need to change the server side config in that case. > > > > Yufei > > > > > > On Wed, Jun 25, 2025 at 3:32 PM Dmitri Bour

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

You should check in the archive (it’s what I did). > > > > > > > > Regards > > > > JB > > > > > > > > Le mar. 24 juin 2025 à 20:24, Dmitri Bourlatchkov > a > > > > écrit : > > > > > > > > > Hi Y

[VOTE] Release Apache Polaris 1.0.0-incubating (RC2)

Hi everyone, I propose that we release the following RC as the official Apache Polaris 1.0.0-incubating release. This corresponds to the tag: apache-polaris-1.0.0-incubating-rc2 * https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc2 * https://github.com/apache/polaris/tre

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC1)

Cancelling RC1 due to the Helm Chart versioning fix. More context in https://github.com/apache/polaris/pull/1944 and https://lists.apache.org/thread/d1vf7xpn6nkzp8gbh417m8qb58tkpcqz Yufei On Wed, Jun 25, 2025 at 11:48 AM Yufei Gu wrote: > A quick correction: the correct tag name is >

Re: [DISCUSS] Prepare for 1.0 Release

ql.DataSource]" on the current > `main`. I do not know what regressed, though. > > I think we have to fix this for 1.0. > > Cheers, > Dmitri. > > On Wed, Jun 25, 2025 at 6:11 PM Yufei Gu wrote: > > > Thanks for raising this, Dmitri! One minor question, does

Re: [DISCUSS] Prepare for 1.0 Release

wrote: > Hi All, > > Do you think we should include this new issue into 1.0? > > https://github.com/apache/polaris/issues/1943 > > Thanks, > Dmitri. > > On Mon, Jun 23, 2025 at 9:32 PM Yufei Gu wrote: > > > Thanks a lot for everyone working on this!

Re: [DISCUSS] Separate Helm charts release

Thanks Dmitri for raising this. Thanks all for the discussion. Can we conclude this thread? Here are some points we discussed(1, 2, 3) + my suggestion for versioning(4,5): 1. Publish the Helm Chart along with Polaris src/bin release. 2. Publish the Helm Chart to dist.apache.org 3. Using the same v

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

apache-polaris-1.0.0-incubating.tar.gz > * polaris-bin-1.0.0-incubating.tgz > > I believe binary archives should have "apache-polaris" as a name prefix. > > [1] > > https://dist.apache.org/repos/dist/dev/incubator/polaris/apache-polaris-1.0.0-incubating > > Cheers, > Dm

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC1)

A quick correction: the correct tag name is apache-polaris-1.0.0-incubating-rc1. All the provided links remain accurate. Yufei On Wed, Jun 25, 2025 at 11:44 AM Yufei Gu wrote: > Hi everyone, > > I propose that we release the following RC as the official > Apache Polaris 1.0.

[VOTE] Release Apache Polaris 1.0.0-incubating (RC1)

Hi everyone, I propose that we release the following RC as the official Apache Polaris 1.0.0-incubating release. This corresponds to the tag: apache-polaris-1.0.0-incubating-rc0 * https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc1 * https://github.com/apache/polaris/tre

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

th "polaris-1.0.0-incubating.tar.gz" > (source) and "polaris-bin-1.0.0-incubating.tar.gz" (binary). > > Cheers, > Dmitri. > > On Tue, Jun 24, 2025 at 11:32 AM Yufei Gu wrote: > > > > > > > Zip and tarball binaries for `polaris-server` and `po

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

ve an implication in the future. We will need to consolidate versions, which benefits the project in the long-term. For this particular release, I will suggest adding licenses for both versions. WDYT? Yufei On Tue, Jun 24, 2025 at 9:55 AM Yufei Gu wrote: > -- *BLOCKER* LICENSE is not correct

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

tions > before, that's no longer the case. Although that's not a release blocker > for me, it should be aligned to what's been there before. > > > On 24.06.25 17:32, Yufei Gu wrote: > >> Zip and tarball binaries for `polaris-server` and `polaris-admin` are > >>

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

Luckily the last extracted are the good ones > but it's not great. We should exclude LICENSE/NOTICE coming from > shaded dependencies to keep only our LICENSE/NOTICE file. > - the email body/subject txt files can be removed from the dist repository > > I will work with Yufei to

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

ks, > Dmitri. > > On Tue, Jun 24, 2025 at 2:13 PM Yufei Gu wrote: > > > > Is there a particular reason for not consolidating the versions in 1.0? > > > > I'm fine to have it in 1.0, but it doesn't seem like a straighford fix. > We > > may not consid

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

wrote: > Hi Yufei, > > Is there a particular reason for not consolidating the versions in 1.0? > > With Micrometer usually doing a good job at cross-version compatibility I > would not expect it to be a big or risky change. > > Thanks, > Dmitri. > > On Tue, Jun 24,

Re: [DISCUSS] Prepare for 1.0 Release

gt; > > > > > > The first one might have implications to the release? > > > > > > > > > On 23.06.25 13:30, Jean-Baptiste Onofré wrote: > > > > Hi folks, > > > > > > > > I don't see any Issue or PR with the 1.0-blocke

  1   2   3   4   >