Re: [VOTE] Release Apache Polaris 0.10.0-beta-incubating (rc2)

[Dennis Huo]

+1 (binding)

1. Verified checksums
2. Verified running server binary distribution with run.sh and
configuration overrides, feature flags per instructions under
https://polaris.apache.org/in-dev/unreleased/configuration/

On Mon, May 5, 2025 at 11:35 PM Jean-Baptiste Onofré 
wrote:

> Hi Adnan
>
> I think the documentation on the source distribution/release branch is
> fine with the release (it's valid and works imho).
> Improvement on the documentation can be included in the next release.
>
> Regards
> JB
>
> On Mon, May 5, 2025 at 11:39 PM Adnan Hemani
>  wrote:
> >
> > This makes sense to me - but the 0.10 release tag would not line up with
> the shell scripts included in that release if we only changed the docs. But
> if we are following up quickly with 1.0 after this release, then that’s
> also fair. This is not absolutely critical if we are only waiting another
> few weeks for the next release.
> >
> > (Non-binding): +1
> >
> > > On May 5, 2025, at 2:35 PM, Russell Spitzer 
> wrote:
> > >
> > > I think it's also perfectly fine to change docs after the release. We
> would
> > > do so if we had better
> > > descriptions or bug fixes, so I don't see why we couldn't do that for
> > > better how-to guides
> > > as long as the information applied to 0.10.
> > >
> > > On Mon, May 5, 2025 at 4:31 PM Dmitri Bourlatchkov  > wrote:
> > >
> > >> Hi Adnan,
> > >>
> > >> I believe the plan is to follow with 1.0 immediately after 0.10.0 is
> > >> released (as discussed in the community call last week). We should
> > >> certainly include doc changes there... but I do not think they are
> critical
> > >> for another 0.10.0 RC. In fact, making another RC will delay 1.0
> under the
> > >> current plan, I guess.
> > >>
> > >> Users can always refer to the latest docs on the web site.
> > >>
> > >> Cheers,
> > >> Dmitri.
> > >>
> > >> On Mon, May 5, 2025 at 5:20 PM Adnan Hemani
> > >>  wrote:
> > >>
> > >>> (Non-Binding) -1: I think 0.10.0 release would be very positively
> > >> impacted
> > >>> by having the remaining pieces of the Getting Started with Cloud
> > >> Providers
> > >>> (Using Blob Storage) - this PR:
> > >>>
> https://www.google.com/url?q=https://github.com/apache/polaris/pull/1435&source=gmail-imap&ust=174708571800&usg=AOvVaw3DFVNGH7RtQPaotzqq8Tae.
> I understand this was
> > >>> committed past the cut-off, but having it part of the website under
> the
> > >>> 0.10.0 release label will make this tutorial much more easily found
> imo.
> > >>>
> > >>> If there’s any way to cherry-pick this commit in, I’d be a solid +1.
> > >>>
> > >>> Best,
> > >>> Adnan Hemani
> > >>>
> >  On May 2, 2025, at 9:39 PM, Jean-Baptiste Onofré  >
> > >>> wrote:
> > 
> >  Hi everyone,
> > 
> >  Following the fixes done on RC1, I propose that we release the
> >  following RC (RC2) as the official Apache Polaris
> >  0.10.0-beta-incubating release.
> > 
> >  * This corresponds to the tag:
> > >> apache-polaris-0.10.0-beta-incubating-rc2
> >  *
> > >>>
> > >>
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://github.com/apache/polaris/commits/apache-polaris-0.10.0-beta-incubating-rc2%26source%3Dgmail-imap%26ust%3D174685198200%26usg%3DAOvVaw0hShm_QH5BvPJviriz_KAd&source=gmail-imap&ust=174708571800&usg=AOvVaw1DeprjtOm1P_X2x6JX1FSz
> >  *
> > >>>
> > >>
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://github.com/apache/polaris/tree/05d0f8ed15d5d25672eef9297ade9b8e1f1374a2%26source%3Dgmail-imap%26ust%3D174685198200%26usg%3DAOvVaw1vuvQCvdkKIJJMfmKQg9bx&source=gmail-imap&ust=174708571800&usg=AOvVaw1Zk58OTyrfgI42eOuWsVUB
> > 
> >  The release tarball, signature, and checksums are here:
> >  *
> > >>>
> > >>
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://dist.apache.org/repos/dist/dev/incubator/polaris/apache-polaris-0.10.0-beta-incubating%26source%3Dgmail-imap%26ust%3D174685198200%26usg%3DAOvVaw2j5kcZ5tUoykxMsxnwCe1Z&source=gmail-imap&ust=174708571800&usg=AOvVaw10xlWe7pcMgYqLhxXHMj_l
> > 
> >  Helm charts are available on:
> >  *
> > >>>
> > >>
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart%26source%3Dgmail-imap%26ust%3D174685198200%26usg%3DAOvVaw2YFx4hDCs26KmWYwith02O&source=gmail-imap&ust=174708571800&usg=AOvVaw1kJDL6S70iBOupLLMzWP_0
> >  NB: the docker images (polaris-server and polaris-admin) will be
> >  published on DockerHub once release vote passes.
> > 
> >  You can find the KEYS file here:
> >  *
> > >>>
> > >>
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://dist.apache.org/repos/dist/release/incubator/polaris/KEYS%26source%3Dgmail-imap%26ust%3D174685198200%26usg%3DAOvVaw369KzODC21cODAIMKYfMF2&source=gmail-imap&ust=174708571800&usg=AOvVaw2ndCWNJHbxMGXM6ulDDFjO
> > 
> >  Conveni

Re: Merge module polaris-quarkus-admin and polaris-quarkus-server

[Dmitri Bourlatchkov]

Thanks for the clarification, JB!

Packaging both the server and the admin tool in the same distribution
(archive) is certainly a good idea.

Cheers,
Dmitri.

On Tue, May 6, 2025 at 2:33 AM Jean-Baptiste Onofré  wrote:

> Hi
>
> We can see two aspects here:
> - the merge of the applications
> - gather applications in one package/distribution (tar.gz/zip)
>
> I'm in favor of the later because:
> - admin and server distributions share 80% of the same artifacts
> - users have to download to "big" packages
>
> We should keep the Quarkus applications separated but we can gather
> both in one distribution, with this kind of layout:
> - admin/run.sh
> - admin/lib/boot
> - admin/lib/main
> - server/run.sh
> - server/lib/boot
> - server/lib/main
> - lib/common
> I don't see why it could not work with Quarkus (I already did
> something similar for other Quarkus application, using maven assembly
> plugin).
>
> Regards
> JB
>
> On Tue, May 6, 2025 at 2:54 AM Dmitri Bourlatchkov 
> wrote:
> >
> > Hi Yufei,
> >
> > Please note that the admin tool is a CLI application, while the quarkus
> > "server" is a REST application.
> >
> > How do you envision supporting both CLI and REST API in the same module?
> >
> > Thanks,
> > Dmitri.
> >
> > On Mon, May 5, 2025 at 2:49 PM Yufei Gu  wrote:
> >
> > > Hi folks,
> > >
> > >
> > >
> > > I’d like to propose merging the polaris-quarkus-admin and
> > > polaris-quarkus-server modules. While modularization can bring benefits
> > > like clearer separation of concerns, in this case, the split seems to
> cause
> > > more friction than value. Here’s why I think merging makes sense:
> > >
> > >1. Improved usability: Users can find all tools in one place,
> making it
> > >easier to use and onboard. Just try out the new 0.10.0-beta binary
> > >releases, you will find out the inconvenience of the separation.
> Plus, I
> > >don’t think anyone will use the admin tool without Polaris server.
> We
> > >don't have to merge the module to archive a single binary release
> > > package,
> > >but merging two modules will make it really easy.
> > >2. Simpler development: The split has led to small utility modules
> like
> > >“test-common” and “run-script” that only exist to bridge the
> separation.
> > >Merging the two will reduce duplication and save time for everyone.
> > >3. Easier releases: We’d no longer need to generate separate
> > >LICENSE/NOTICE files or maintain two binary packages.
> > >
> > >
> > > I’ve talked to folks like JB and Prashant about this offline, and the
> > > feedback so far has been positive.
> > >
> > >
> > > If there are no objections, I’ll file a PR to merge the two and aim to
> > > package them together starting with the 1.0 release.
> > >
> > >
> > > Yufei
> > >
>

Re: [VOTE] Release Apache Polaris 0.10.0-beta-incubating (rc2)

[Jean-Baptiste Onofré]

+1 (binding)

I checked:
- checksum and signature are good on the source distribution
- in the source distribution, some files don't contain ASF header but
expected (like version.txt, etc)
- no binary file found in the source distribution
- LICENSE and NOTICE looks good in the source distribution
- Build work from the source distribution
- checksum and signature are good on the admin distribution
- admin distribution starts fine (run.sh)
- LICENSE/NOTICE look good on admin distribution
- checksum and signature are good on the server distribution
- server distribution starts fine (run.sh)
- LICENSE/NOTICE look good on server distribution

Regards
JB

JB

On Sat, May 3, 2025 at 6:39 AM Jean-Baptiste Onofré  wrote:
>
> Hi everyone,
>
> Following the fixes done on RC1, I propose that we release the
> following RC (RC2) as the official Apache Polaris
> 0.10.0-beta-incubating release.
>
> * This corresponds to the tag: apache-polaris-0.10.0-beta-incubating-rc2
> * 
> https://github.com/apache/polaris/commits/apache-polaris-0.10.0-beta-incubating-rc2
> * 
> https://github.com/apache/polaris/tree/05d0f8ed15d5d25672eef9297ade9b8e1f1374a2
>
> The release tarball, signature, and checksums are here:
> * 
> https://dist.apache.org/repos/dist/dev/incubator/polaris/apache-polaris-0.10.0-beta-incubating
>
> Helm charts are available on:
> * https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart
> NB: the docker images (polaris-server and polaris-admin) will be
> published on DockerHub once release vote passes.
>
> You can find the KEYS file here:
> * https://dist.apache.org/repos/dist/release/incubator/polaris/KEYS
>
> Convenience binary artifacts are staged on Nexus. The Maven
> repositories URLs are:
> * https://repository.apache.org/content/repositories/orgapachepolaris-1012/
>
> Please download, verify, and test.
>
> Please vote in the next 72 hours.
>
> [ ] +1 Release this as Apache polaris 0.10.0-beta-incubating
> [ ] +0
> [ ] -1 Do not release this because...
>
> Only PPMC members and mentors have binding votes, but other community
> members are
> encouraged to cast non-binding votes. This vote will pass if there are
> 3 binding +1 votes and more binding +1 votes than -1 votes.
>
> NB: if this vote passes, a new vote has to be started on the Incubator
> general mailing
> list.
>
> Thanks
> Regards
>
> JB

Re: [VOTE] Release Apache Polaris 0.10.0-beta-incubating (rc2)

[Prashant Singh]

+1

1. Verified checksums, signature, artifacts
2. did manual testing with admin and server, works well !

Best,
Prashant Singh

On Tue, May 6, 2025 at 7:52 AM Jean-Baptiste Onofré  wrote:

> +1 (binding)
>
> I checked:
> - checksum and signature are good on the source distribution
> - in the source distribution, some files don't contain ASF header but
> expected (like version.txt, etc)
> - no binary file found in the source distribution
> - LICENSE and NOTICE looks good in the source distribution
> - Build work from the source distribution
> - checksum and signature are good on the admin distribution
> - admin distribution starts fine (run.sh)
> - LICENSE/NOTICE look good on admin distribution
> - checksum and signature are good on the server distribution
> - server distribution starts fine (run.sh)
> - LICENSE/NOTICE look good on server distribution
>
> Regards
> JB
>
> JB
>
> On Sat, May 3, 2025 at 6:39 AM Jean-Baptiste Onofré 
> wrote:
> >
> > Hi everyone,
> >
> > Following the fixes done on RC1, I propose that we release the
> > following RC (RC2) as the official Apache Polaris
> > 0.10.0-beta-incubating release.
> >
> > * This corresponds to the tag: apache-polaris-0.10.0-beta-incubating-rc2
> > *
> https://github.com/apache/polaris/commits/apache-polaris-0.10.0-beta-incubating-rc2
> > *
> https://github.com/apache/polaris/tree/05d0f8ed15d5d25672eef9297ade9b8e1f1374a2
> >
> > The release tarball, signature, and checksums are here:
> > *
> https://dist.apache.org/repos/dist/dev/incubator/polaris/apache-polaris-0.10.0-beta-incubating
> >
> > Helm charts are available on:
> > * https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart
> > NB: the docker images (polaris-server and polaris-admin) will be
> > published on DockerHub once release vote passes.
> >
> > You can find the KEYS file here:
> > * https://dist.apache.org/repos/dist/release/incubator/polaris/KEYS
> >
> > Convenience binary artifacts are staged on Nexus. The Maven
> > repositories URLs are:
> > *
> https://repository.apache.org/content/repositories/orgapachepolaris-1012/
> >
> > Please download, verify, and test.
> >
> > Please vote in the next 72 hours.
> >
> > [ ] +1 Release this as Apache polaris 0.10.0-beta-incubating
> > [ ] +0
> > [ ] -1 Do not release this because...
> >
> > Only PPMC members and mentors have binding votes, but other community
> > members are
> > encouraged to cast non-binding votes. This vote will pass if there are
> > 3 binding +1 votes and more binding +1 votes than -1 votes.
> >
> > NB: if this vote passes, a new vote has to be started on the Incubator
> > general mailing
> > list.
> >
> > Thanks
> > Regards
> >
> > JB
>

Re: [DISCUSS] Deprecate Eclipse Link and make Relational JDBC as default

[Dmitri Bourlatchkov]

I'd propose to convert all existing tests that use a Postgres database to
JDBC.

Then (in the same PR) add dedicated integration tests for EclipseLink
following the same approach that was used for JDBC ITs.

This ensures that EclipseLink is covered by the normative Polaris
"integration-tests". At the same time, all tests that are not normative
from the Persistence perspective (perhaps they test something else... I did
not check), use the new default persistence (JDBC).

WDYT?

Thanks,
Dmitri.

On Tue, May 6, 2025 at 2:48 AM Jean-Baptiste Onofré  wrote:

> Hi
>
> My point is that we should have tests for both EclipseLink and JDBC
> (parameterized).
> I think it's acceptable to have "longer tests", just to be sure
> EclipseLink still works fine (waiting to remove it).
>
> Regards
> JB
>
> On Tue, May 6, 2025 at 12:17 AM Dmitri Bourlatchkov 
> wrote:
> >
> > Good point about tests!
> >
> > However, I believe it still makes sense to transfer the main body of
> tests
> > using a "real database" to JDBC. It should be possible to run one
> > Integration test on EclipseLink to make sure it works and still not
> > overload CI.
> >
> > Cheers,
> > Dmitri.
> >
> >
> > On Mon, May 5, 2025 at 1:26 PM Jean-Baptiste Onofré 
> wrote:
> >
> > > Hi
> > >
> > > I already commented on the PR and forgot to reply here :)
> > >
> > > Yes agree to deprecate eclipselink it makes sense to me and promote
> > > "JDBC" instead.
> > >
> > > That said, as said in the PR, I think we should keep the eclipselink
> > > test still (even if deprecated): deprecation gives time for users to
> > > "move to" JDBC but they can still use eclipselink, so it makes sense
> > > to test it to be sure it works and there's no regression here.
> > >
> > > Just my $0.01 :)
> > >
> > > Regards
> > > JB
> > >
> > > On Fri, May 2, 2025 at 11:59 PM Prashant Singh
> > >  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I’d like to get your thoughts on deprecating EclipseLink and making
> JDBC
> > > > the default for our persistence layer.
> > > >
> > > > Our current EclipseLink setup mandates execution within a
> transaction,
> > > > which has introduced several issues — notably, an improper
> implementation
> > > > of CAS (compare-and-swap) semantics. To address these shortcomings,
> > > Apache
> > > > Polaris underwent a major refactor to decouple persistence interfaces
> > > from
> > > > strict transaction dependencies and to ensure actual CAS enforcement.
> > > >
> > > > As part of this effort, we introduced a new JDBC backend with a
> simpler
> > > and
> > > > more performant schema, directly addressing the limitations of the
> > > existing
> > > > EclipseLink schema.
> > > >
> > > > We’ve observed significant improvements compared to the EclipseLink
> > > > implementation. Notably, issues such as Polaris failing under minimal
> > > > concurrency (e.g., with just 5 users) have been resolved:
> > > >
> https://github.com/apache/polaris/issues/1123#issuecomment-2756133924
> > > >
> > > > Given these improvements, I propose we:
> > > >
> > > >-
> > > >
> > > >Deprecate EclipseLink
> > > >-
> > > >
> > > >Make relational JDBC the default persistence implementation
> > > >
> > > > PR to support this change:
> > > > [1] https://github.com/apache/polaris/pull/1515
> > > >
> > > > Would love to hear your feedback on this.
> > > >
> > > > Best regards,
> > > > Prashant
> > >
>

Re: [VOTE] Release Apache Polaris 0.10.0-beta-incubating (rc2)

[Honah J.]

+1 (non-binding)

1. Verified signatures and checksums
2. Build and local tests all look good.

Best,
Jonas

On Tue, May 6, 2025 at 8:44 AM Prashant Singh
 wrote:

> +1
>
> 1. Verified checksums, signature, artifacts
> 2. did manual testing with admin and server, works well !
>
> Best,
> Prashant Singh
>
> On Tue, May 6, 2025 at 7:52 AM Jean-Baptiste Onofré 
> wrote:
>
> > +1 (binding)
> >
> > I checked:
> > - checksum and signature are good on the source distribution
> > - in the source distribution, some files don't contain ASF header but
> > expected (like version.txt, etc)
> > - no binary file found in the source distribution
> > - LICENSE and NOTICE looks good in the source distribution
> > - Build work from the source distribution
> > - checksum and signature are good on the admin distribution
> > - admin distribution starts fine (run.sh)
> > - LICENSE/NOTICE look good on admin distribution
> > - checksum and signature are good on the server distribution
> > - server distribution starts fine (run.sh)
> > - LICENSE/NOTICE look good on server distribution
> >
> > Regards
> > JB
> >
> > JB
> >
> > On Sat, May 3, 2025 at 6:39 AM Jean-Baptiste Onofré 
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > Following the fixes done on RC1, I propose that we release the
> > > following RC (RC2) as the official Apache Polaris
> > > 0.10.0-beta-incubating release.
> > >
> > > * This corresponds to the tag:
> apache-polaris-0.10.0-beta-incubating-rc2
> > > *
> >
> https://github.com/apache/polaris/commits/apache-polaris-0.10.0-beta-incubating-rc2
> > > *
> >
> https://github.com/apache/polaris/tree/05d0f8ed15d5d25672eef9297ade9b8e1f1374a2
> > >
> > > The release tarball, signature, and checksums are here:
> > > *
> >
> https://dist.apache.org/repos/dist/dev/incubator/polaris/apache-polaris-0.10.0-beta-incubating
> > >
> > > Helm charts are available on:
> > > * https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart
> > > NB: the docker images (polaris-server and polaris-admin) will be
> > > published on DockerHub once release vote passes.
> > >
> > > You can find the KEYS file here:
> > > * https://dist.apache.org/repos/dist/release/incubator/polaris/KEYS
> > >
> > > Convenience binary artifacts are staged on Nexus. The Maven
> > > repositories URLs are:
> > > *
> >
> https://repository.apache.org/content/repositories/orgapachepolaris-1012/
> > >
> > > Please download, verify, and test.
> > >
> > > Please vote in the next 72 hours.
> > >
> > > [ ] +1 Release this as Apache polaris 0.10.0-beta-incubating
> > > [ ] +0
> > > [ ] -1 Do not release this because...
> > >
> > > Only PPMC members and mentors have binding votes, but other community
> > > members are
> > > encouraged to cast non-binding votes. This vote will pass if there are
> > > 3 binding +1 votes and more binding +1 votes than -1 votes.
> > >
> > > NB: if this vote passes, a new vote has to be started on the Incubator
> > > general mailing
> > > list.
> > >
> > > Thanks
> > > Regards
> > >
> > > JB
> >
>

Re: Merge module polaris-quarkus-admin and polaris-quarkus-server

[Yufei Gu]

Other than duplicated downloads for shared jars, the big problem is that
the configuration difference between admin tool and server may cause server
issues, e.g., the admin tool may bootstrap a realm in a wrong database.

Let's move them into the same distribution package first. Then we can
consider merging the modules, as we discussed the separation makes the
development and release unnecessary cumbersome.

Yufei


On Tue, May 6, 2025 at 5:57 AM Dmitri Bourlatchkov  wrote:

> Thanks for the clarification, JB!
>
> Packaging both the server and the admin tool in the same distribution
> (archive) is certainly a good idea.
>
> Cheers,
> Dmitri.
>
> On Tue, May 6, 2025 at 2:33 AM Jean-Baptiste Onofré 
> wrote:
>
> > Hi
> >
> > We can see two aspects here:
> > - the merge of the applications
> > - gather applications in one package/distribution (tar.gz/zip)
> >
> > I'm in favor of the later because:
> > - admin and server distributions share 80% of the same artifacts
> > - users have to download to "big" packages
> >
> > We should keep the Quarkus applications separated but we can gather
> > both in one distribution, with this kind of layout:
> > - admin/run.sh
> > - admin/lib/boot
> > - admin/lib/main
> > - server/run.sh
> > - server/lib/boot
> > - server/lib/main
> > - lib/common
> > I don't see why it could not work with Quarkus (I already did
> > something similar for other Quarkus application, using maven assembly
> > plugin).
> >
> > Regards
> > JB
> >
> > On Tue, May 6, 2025 at 2:54 AM Dmitri Bourlatchkov 
> > wrote:
> > >
> > > Hi Yufei,
> > >
> > > Please note that the admin tool is a CLI application, while the quarkus
> > > "server" is a REST application.
> > >
> > > How do you envision supporting both CLI and REST API in the same
> module?
> > >
> > > Thanks,
> > > Dmitri.
> > >
> > > On Mon, May 5, 2025 at 2:49 PM Yufei Gu  wrote:
> > >
> > > > Hi folks,
> > > >
> > > >
> > > >
> > > > I’d like to propose merging the polaris-quarkus-admin and
> > > > polaris-quarkus-server modules. While modularization can bring
> benefits
> > > > like clearer separation of concerns, in this case, the split seems to
> > cause
> > > > more friction than value. Here’s why I think merging makes sense:
> > > >
> > > >1. Improved usability: Users can find all tools in one place,
> > making it
> > > >easier to use and onboard. Just try out the new 0.10.0-beta binary
> > > >releases, you will find out the inconvenience of the separation.
> > Plus, I
> > > >don’t think anyone will use the admin tool without Polaris server.
> > We
> > > >don't have to merge the module to archive a single binary release
> > > > package,
> > > >but merging two modules will make it really easy.
> > > >2. Simpler development: The split has led to small utility modules
> > like
> > > >“test-common” and “run-script” that only exist to bridge the
> > separation.
> > > >Merging the two will reduce duplication and save time for
> everyone.
> > > >3. Easier releases: We’d no longer need to generate separate
> > > >LICENSE/NOTICE files or maintain two binary packages.
> > > >
> > > >
> > > > I’ve talked to folks like JB and Prashant about this offline, and the
> > > > feedback so far has been positive.
> > > >
> > > >
> > > > If there are no objections, I’ll file a PR to merge the two and aim
> to
> > > > package them together starting with the 1.0 release.
> > > >
> > > >
> > > > Yufei
> > > >
> >
>