Re: [DISCUSS] On-going CHANGELOG with breaking changes

[Yufei Gu]

It does seem to introduce quite a bit of manual overhead. I’m personally
not a big fan of that, but I’m open to trying it out. That said, I believe
the release manager should have the ability to organize the changelog at
release time, since it’s quite difficult to maintain consistency from the
perspective of individual PRs. For example, contributors might add
something, then revise or remove it later. If the changelog entries are
immutable, the history could become messy and confusing. Dmitri mentioned
that changelog could be updated by PRs, which seems a reasonable fixing
resort to me.

Yufei


On Thu, May 15, 2025 at 7:27 PM Jean-Baptiste Onofré 
wrote:

> Hi Dimitri
>
> It's a good idea.
>
> I think each committer should be responsible to update the CHANGELOG
> if appropriate, and reviewer should point it out if needed.
>
> It's the same as documentation, license update and header (when code
> is copied from another project), etc.
>
> Regards
> JB
>
> On Thu, May 15, 2025 at 9:10 PM Dmitri Bourlatchkov 
> wrote:
> >
> > Hi All,
> >
> > As discussed in the community sync today, Polaris evolves quickly and
> > breaking changes are a reality we have to live with :)
> >
> > However, I'd like to propose improving user and developer experience by
> > keeping a change log with a section for breaking changes.
> >
> > We follow this practice in Nessie [1] with the help of the
> > "jetbrains-changelog" build plugin to automate adding versioned sections
> [2]
> >
> > * PRs that have strong user-visible effects also update the appropriate
> > section of the change log.
> > * At release time, the "in progress" entries are moved to a version
> > sub-section automatically.
> > * I'd also propose additionally mentioning PRs with "breaking changes" on
> > the dev ML list before merging.
> >
> > WDYT about introducing this workflow in Polaris?
> >
> > Thanks,
> > Dmitri.
> >
> > [1] https://github.com/projectnessie/nessie/blob/main/CHANGELOG.md
> > [2] https://github.com/projectnessie/nessie/pull/7243
>

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

[Prashant Singh]

Apologies for not getting back at this earlier. I somehow missed this email
thread.
To conclude the discussion we ended up doing the following :
[1] The service tests run with JDBC / in-memory persistence
[2] Admin tests (JDBC / EclipseLink persistence)

Again thanks a ton everyone ! for your feedback and work !

Given that now we have achieved *Deprecate Eclipse Link and make Relational
JDBC as default*
via our docs and getting started etc reflect that very well !

I wanted to bring closing this issue as well :
https://github.com/apache/polaris/issues/777#top
As we no longer endorse Eclipse link which is where this originated from
and the current JDBC the default persistence
is very much permissive of the concurrent workload as demonstrated by :
https://lists.apache.org/thread/bz80l2fhtbfz3pqyfqp1c39ymmyqkc85

Please let me know you thoughts considering the same ^^^


Best,
Prashant Singh




On Tue, May 6, 2025 at 8:59 AM Dmitri Bourlatchkov  wrote:

> 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
> > > >
> >
>

[DISCUSS] Remove realm_id metric tag

[Alex Dutra]

Hi all,

I would like to suggest removing the "realm_id" metric tag entirely.

My concern is that this tag has the potential for high cardinality, which
is generally considered a bad practice when dealing with metrics. High
cardinality can lead to performance issues and increased memory usage.

Granted, the default realm resolver in Polaris is tailored for just a
handful of realms, but nothing prevents users from declaring hundreds of
realms.

I believe we can still effectively monitor Polaris servers without this
specific tag, since the realm ID is also propagated in traces emitted by
Polaris. Tracing is a much better fit for high-cardinality domains.

I'm open to discussing this further; a potential alternative would be to
introduce a flag to disable this specific metric tag, but I feel like
removing it would be a much cleaner approach.

Let me know your thoughts.

Thanks,

Alex

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

[Jean-Baptiste Onofré]

Hi Yufei

Thanks for the PR (I left one comment in there).

About naming, I think we should use polaris-{version}-bin for clarity.

I will work on LICENSE, NOTICE, DISCLAIMER for this distribution as it
has to be "merged".

Regards
JB

On Wed, May 14, 2025 at 8:32 PM Yufei Gu  wrote:
>
> Hi Folk,
> Thanks a lot for the discussion. Here is the PR(
> https://github.com/apache/polaris/pull/1589) to merge the binary
> distribution while still keeping module polaris-quarkus-admin and
> polaris-quarkus-server separately.
>
> *What’s included in the PR:*
>
>1. Introduced a new module that combines binary distribution for both
>Admin Tools and Server. Please note that source and jar are still
>separated. Please refer to my original email for the motivation behind this
>change.
>2. Removed the now-redundant run-scripts module.
>3. Consolidated the README to reflect the unified binary distribution.
>4. Standardized the binary distribution package naming to
>polaris-{version}.tgz and polaris-{version}.zip, following common
>conventions used by other projects (e.g., spark-3.5.5-bin-hadoop3.tgz).
>
> *TODOs*:
>
>1. Consolidate LICENSE and NOTICE files from both Admin Tools and Server.
>2. Remove the distribution tasks in each of the original modules.
>
> The PR is technically ready, but I plan to wait until the 0.10 release is
> finalized to avoid disrupting the release process.
>
>
> Yufei
>
>
> On Tue, May 6, 2025 at 9:31 AM Yufei Gu  wrote:
>
> > 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 

Re: [DISCUSS] On-going CHANGELOG with breaking changes

[Yufei Gu]

Thanks for kicking this off, Dmitri—great idea!

Looking at the current CHANGELOG, the entries range from PR-number
references to detailed feature write-ups and even small tweaks like “make
test less flaky.” To keep it useful, we probably need a consistent format.

Who should own that consistency? Should the release manager normalize
entries at cut time, or should each PR author follow a template up front?


Yufei


On Thu, May 15, 2025 at 12:10 PM Dmitri Bourlatchkov 
wrote:

> Hi All,
>
> As discussed in the community sync today, Polaris evolves quickly and
> breaking changes are a reality we have to live with :)
>
> However, I'd like to propose improving user and developer experience by
> keeping a change log with a section for breaking changes.
>
> We follow this practice in Nessie [1] with the help of the
> "jetbrains-changelog" build plugin to automate adding versioned sections
> [2]
>
> * PRs that have strong user-visible effects also update the appropriate
> section of the change log.
> * At release time, the "in progress" entries are moved to a version
> sub-section automatically.
> * I'd also propose additionally mentioning PRs with "breaking changes" on
> the dev ML list before merging.
>
> WDYT about introducing this workflow in Polaris?
>
> Thanks,
> Dmitri.
>
> [1] https://github.com/projectnessie/nessie/blob/main/CHANGELOG.md
> [2] https://github.com/projectnessie/nessie/pull/7243
>

[DISCUSS] On-going CHANGELOG with breaking changes

[Dmitri Bourlatchkov]

Hi All,

As discussed in the community sync today, Polaris evolves quickly and
breaking changes are a reality we have to live with :)

However, I'd like to propose improving user and developer experience by
keeping a change log with a section for breaking changes.

We follow this practice in Nessie [1] with the help of the
"jetbrains-changelog" build plugin to automate adding versioned sections [2]

* PRs that have strong user-visible effects also update the appropriate
section of the change log.
* At release time, the "in progress" entries are moved to a version
sub-section automatically.
* I'd also propose additionally mentioning PRs with "breaking changes" on
the dev ML list before merging.

WDYT about introducing this workflow in Polaris?

Thanks,
Dmitri.

[1] https://github.com/projectnessie/nessie/blob/main/CHANGELOG.md
[2] https://github.com/projectnessie/nessie/pull/7243

Re: [DISCUSS] On-going CHANGELOG with breaking changes

[Russell Spitzer]

These seem like good ideas to me. I'd prefer things with minimal human
interactions in the loop but
 having dev emails for changing intra-release breaking commits sounds good
to me.

On Thu, May 15, 2025 at 2:30 PM Yufei Gu  wrote:

> Thanks for kicking this off, Dmitri—great idea!
>
> Looking at the current CHANGELOG, the entries range from PR-number
> references to detailed feature write-ups and even small tweaks like “make
> test less flaky.” To keep it useful, we probably need a consistent format.
>
> Who should own that consistency? Should the release manager normalize
> entries at cut time, or should each PR author follow a template up front?
>
>
> Yufei
>
>
> On Thu, May 15, 2025 at 12:10 PM Dmitri Bourlatchkov 
> wrote:
>
> > Hi All,
> >
> > As discussed in the community sync today, Polaris evolves quickly and
> > breaking changes are a reality we have to live with :)
> >
> > However, I'd like to propose improving user and developer experience by
> > keeping a change log with a section for breaking changes.
> >
> > We follow this practice in Nessie [1] with the help of the
> > "jetbrains-changelog" build plugin to automate adding versioned sections
> > [2]
> >
> > * PRs that have strong user-visible effects also update the appropriate
> > section of the change log.
> > * At release time, the "in progress" entries are moved to a version
> > sub-section automatically.
> > * I'd also propose additionally mentioning PRs with "breaking changes" on
> > the dev ML list before merging.
> >
> > WDYT about introducing this workflow in Polaris?
> >
> > Thanks,
> > Dmitri.
> >
> > [1] https://github.com/projectnessie/nessie/blob/main/CHANGELOG.md
> > [2] https://github.com/projectnessie/nessie/pull/7243
> >
>

Invitation: Polaris 1.0 release sync @ Mon 2025-05-19 9am - 10am (PDT) (dev@polaris.apache.org)

[Yufei Gu]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20250519T09
DTEND;TZID=America/Los_Angeles:20250519T10
DTSTAMP:20250515T190818Z
ORGANIZER;CN=Yufei Gu:mailto:flyrain...@gmail.com
UID:6insqaj4tfldvoq2ormf004...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dev@polaris.apache.org;X-NUM-GUESTS=0:mailto:dev@polaris.apache.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Yufei Gu;X-NUM-GUESTS=0:mailto:flyrain...@gmail.com
X-GOOGLE-CONFERENCE:https://meet.google.com/gcc-uvrz-okg
X-MICROSOFT-CDO-OWNERAPPTID:411343592
CREATED:20250515T190816Z
DESCRIPTION:Many users have been asking
  about the Polaris release\, and I believe it's critical for us to have a <
 b>formal\, production-ready 1.0 release ASAP. Thanks to the comm
 unity’s hard work\, we’re very close. We will discuss 1.0 scope as well as 
 existing blockers. \n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nJoin with Google Meet: https:
 //meet.google.com/gcc-uvrz-okg\n\nLearn more about Meet at: https://support
 .google.com/a/users/answer/9282720\n\nPlease do not edit this section.\n-::
 ~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~::~:~::-
LAST-MODIFIED:20250515T190817Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Polaris 1.0 release sync
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H10M0S
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [DISCUSS] On-going CHANGELOG with breaking changes

[Dmitri Bourlatchkov]

Who should own that consistency? Should the release manager normalize
entries at cut time, or should each PR author follow a template up front?


I'd think it's the reviewers' (committers') duty to ensure consistency.

PR authors are encouraged to add entries to CHANGELOG as needed,
but reviewers should be mindful and suggest doing that if they perceive
the PR changes Polaris behaviours in ways that are worth noting.

Conversely, reviewers should reject noise from CHANGELOG.

As for me, CHANGELOG entries are free-form text without a particular
template.

PR references are fine. They give details about how a change was implemented
to interested readers and they do not cause too much clutter for
uninterested
readers, IMHO.

I do not think release managers should handle that file manually during the
release process. If there's a problem with the format or content, it would
need
a normal PR to fix.

Cheers,
Dmitri.

On Thu, May 15, 2025 at 3:30 PM Yufei Gu  wrote:

> Thanks for kicking this off, Dmitri—great idea!
>
> Looking at the current CHANGELOG, the entries range from PR-number
> references to detailed feature write-ups and even small tweaks like “make
> test less flaky.” To keep it useful, we probably need a consistent format.
>
> Who should own that consistency? Should the release manager normalize
> entries at cut time, or should each PR author follow a template up front?
>
>
> Yufei
>
>
> On Thu, May 15, 2025 at 12:10 PM Dmitri Bourlatchkov 
> wrote:
>
> > Hi All,
> >
> > As discussed in the community sync today, Polaris evolves quickly and
> > breaking changes are a reality we have to live with :)
> >
> > However, I'd like to propose improving user and developer experience by
> > keeping a change log with a section for breaking changes.
> >
> > We follow this practice in Nessie [1] with the help of the
> > "jetbrains-changelog" build plugin to automate adding versioned sections
> > [2]
> >
> > * PRs that have strong user-visible effects also update the appropriate
> > section of the change log.
> > * At release time, the "in progress" entries are moved to a version
> > sub-section automatically.
> > * I'd also propose additionally mentioning PRs with "breaking changes" on
> > the dev ML list before merging.
> >
> > WDYT about introducing this workflow in Polaris?
> >
> > Thanks,
> > Dmitri.
> >
> > [1] https://github.com/projectnessie/nessie/blob/main/CHANGELOG.md
> > [2] https://github.com/projectnessie/nessie/pull/7243
> >
>

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

[Dmitri Bourlatchkov]

As commented in GH, I'm fine with closing
https://github.com/apache/polaris/issues/777 now.

Cheers,
Dmitri.


On Thu, May 15, 2025 at 4:13 PM Prashant Singh
 wrote:

> Apologies for not getting back at this earlier. I somehow missed this email
> thread.
> To conclude the discussion we ended up doing the following :
> [1] The service tests run with JDBC / in-memory persistence
> [2] Admin tests (JDBC / EclipseLink persistence)
>
> Again thanks a ton everyone ! for your feedback and work !
>
> Given that now we have achieved *Deprecate Eclipse Link and make Relational
> JDBC as default*
> via our docs and getting started etc reflect that very well !
>
> I wanted to bring closing this issue as well :
> https://github.com/apache/polaris/issues/777#top
> As we no longer endorse Eclipse link which is where this originated from
> and the current JDBC the default persistence
> is very much permissive of the concurrent workload as demonstrated by :
> https://lists.apache.org/thread/bz80l2fhtbfz3pqyfqp1c39ymmyqkc85
>
> Please let me know you thoughts considering the same ^^^
>
>
> Best,
> Prashant Singh
>
>
>
>
> On Tue, May 6, 2025 at 8:59 AM Dmitri Bourlatchkov 
> wrote:
>
> > 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.
> > > > > >
> > 

[DISCUSS] Prepare for 1.0 Release

[Yufei Gu]

Hi folks,

Many users have been asking about the Polaris release, and I believe it's
critical to have a formal, production-ready 1.0 release ASAP. Thanks to the
community’s hard work, we’re very close with a few remaining blockers we
need to resolve.

To keep things moving, I scheduled a community meeting for the 1.0 release
next Monday at 9 AM PST.  At the same time, sharing all issues marked with
1.0 blocker. We could resolve them here if possible. Feel free to chime in,
remove the blocker tag if you think it's not a blocker, or pick any up.
Thanks a lot in advance!

Here is the list:

   - Add CI for Python code (
  #1058),
  - Polaris persistence concurrency issues (#777)
  
  - Task handling is incomplete (#774)
  
  - Generated files in regtests/client/python/polaris (#755)
  
  - Resources not properly closed, resource & memory leaks (#563)
  
  - Make Polaris safe against certain unparseable locations (#552)
  
  - [BUG] Assumption that cache eviction does not happen (#544)
  

To make it more interactive, you can also comment on the google
spreadsheet here:
https://docs.google.com/spreadsheets/d/1GyLvp2cdYwioOsBwszNWiphZt_IIdo4LIfsZBFV88mc/edit?usp=sharing

Yufei

Re: [DISCUSS] On-going CHANGELOG with breaking changes

[Jean-Baptiste Onofré]

Hi Dimitri

It's a good idea.

I think each committer should be responsible to update the CHANGELOG
if appropriate, and reviewer should point it out if needed.

It's the same as documentation, license update and header (when code
is copied from another project), etc.

Regards
JB

On Thu, May 15, 2025 at 9:10 PM Dmitri Bourlatchkov  wrote:
>
> Hi All,
>
> As discussed in the community sync today, Polaris evolves quickly and
> breaking changes are a reality we have to live with :)
>
> However, I'd like to propose improving user and developer experience by
> keeping a change log with a section for breaking changes.
>
> We follow this practice in Nessie [1] with the help of the
> "jetbrains-changelog" build plugin to automate adding versioned sections [2]
>
> * PRs that have strong user-visible effects also update the appropriate
> section of the change log.
> * At release time, the "in progress" entries are moved to a version
> sub-section automatically.
> * I'd also propose additionally mentioning PRs with "breaking changes" on
> the dev ML list before merging.
>
> WDYT about introducing this workflow in Polaris?
>
> Thanks,
> Dmitri.
>
> [1] https://github.com/projectnessie/nessie/blob/main/CHANGELOG.md
> [2] https://github.com/projectnessie/nessie/pull/7243

Re: [DISCUSS] Prepare for 1.0 Release

[Jean-Baptiste Onofré]

Hi Yufei

Thanks for your message !

It looks good to me.

As prerequisite (obviously), we should also complete
0.10.0-beta-incubating release to be sure we are good there before
1.0.0.

Just a comment: I think we should limit the number of community
meetings. This topic should be typically discussed on the mailing list
(as you are doing :)).
The reasons why I'm not big fan of too much meeetings are:
1. No everyone in the community can join (due to timezone, not willing
to speak/appear on call, ...)
2. It puts "pressure" on the community to attend ("if I'm not in the
meeting, I'm not in the community" issue)
3. Due to 1 & 2, no decision should be taken in meetings, and even if
meetings are recorded, it's not archive as mailing list
So, I encourage meetings as community meet&greed, or to discuss about
specific topics, not decision making topic.

Thanks,
Regards
JB


On Thu, May 15, 2025 at 11:38 PM Yufei Gu  wrote:
>
> Hi folks,
>
> Many users have been asking about the Polaris release, and I believe it's
> critical to have a formal, production-ready 1.0 release ASAP. Thanks to the
> community’s hard work, we’re very close with a few remaining blockers we
> need to resolve.
>
> To keep things moving, I scheduled a community meeting for the 1.0 release
> next Monday at 9 AM PST.  At the same time, sharing all issues marked with
> 1.0 blocker. We could resolve them here if possible. Feel free to chime in,
> remove the blocker tag if you think it's not a blocker, or pick any up.
> Thanks a lot in advance!
>
> Here is the list:
>
>- Add CI for Python code (
>   #1058),
>   - Polaris persistence concurrency issues (#777)
>   
>   - Task handling is incomplete (#774)
>   
>   - Generated files in regtests/client/python/polaris (#755)
>   
>   - Resources not properly closed, resource & memory leaks (#563)
>   
>   - Make Polaris safe against certain unparseable locations (#552)
>   
>   - [BUG] Assumption that cache eviction does not happen (#544)
>   
>
> To make it more interactive, you can also comment on the google
> spreadsheet here:
> https://docs.google.com/spreadsheets/d/1GyLvp2cdYwioOsBwszNWiphZt_IIdo4LIfsZBFV88mc/edit?usp=sharing
>
> Yufei

Re: [DISCUSS] Prepare for 1.0 Release

[Dmitri Bourlatchkov]

My take on some of these issues:

* #777 (persistence concurrency) can be closed.
* #552 (odd locations) is not a 1.0 blocker (but needs to be addressed)

Additionally, I think https://github.com/apache/polaris/pull/1532 also
needs to be addressed for 1.0 at least in most aspects. In order to
enable gradual progress while taking more time to resolve controversial
points, IMHO, https://github.com/apache/polaris/pull/1566 could be merged
first.

More specifically, I believe the user-facing warnings in 1532 need to be
added for 1.0, however, I can see that people have different opinions on
how exactly those warnings should be implemented... This is why I think
1566 might be worth merging first, even though it will create additional
rebasing / reworking burden on 1532.

No opinion on other issues.

Cheers,
Dmitri.

On Thu, May 15, 2025 at 5:39 PM Yufei Gu  wrote:

> Hi folks,
>
> Many users have been asking about the Polaris release, and I believe it's
> critical to have a formal, production-ready 1.0 release ASAP. Thanks to the
> community’s hard work, we’re very close with a few remaining blockers we
> need to resolve.
>
> To keep things moving, I scheduled a community meeting for the 1.0 release
> next Monday at 9 AM PST.  At the same time, sharing all issues marked with
> 1.0 blocker. We could resolve them here if possible. Feel free to chime in,
> remove the blocker tag if you think it's not a blocker, or pick any up.
> Thanks a lot in advance!
>
> Here is the list:
>
>- Add CI for Python code (
>   #1058),
>   - Polaris persistence concurrency issues (#777)
>   
>   - Task handling is incomplete (#774)
>   
>   - Generated files in regtests/client/python/polaris (#755)
>   
>   - Resources not properly closed, resource & memory leaks (#563)
>   
>   - Make Polaris safe against certain unparseable locations (#552)
>   
>   - [BUG] Assumption that cache eviction does not happen (#544)
>   
>
> To make it more interactive, you can also comment on the google
> spreadsheet here:
>
> https://docs.google.com/spreadsheets/d/1GyLvp2cdYwioOsBwszNWiphZt_IIdo4LIfsZBFV88mc/edit?usp=sharing
>
> Yufei
>