Hi All,
Posting for visibility.
In PR [1955] I propose to avoid serializing null property values to clients.
This change does have some risk of breaking existing clients, but the risk
is minimal IMHO. Only clients that rely on observing explicit records for
null properties are affected.
This sho
Building from current RC2 tag, I see these licenses in the spark bundle:
$ jar tvf polaris-spark-3.5_2.12-1.1.0-incubating-SNAPSHOT-bundle.jar|grep
LIC
15980 Fri Feb 01 00:00:00 EST 1980 LICENSE
11358 Fri Feb 01 00:00:00 EST 1980 META-INF/LICENSE
13425 Fri Feb 01 00:00:00 EST 1980
META-INF/lice
RC2 looks good so far.
I'm not voting expecting a formal RC3 later, as discussed.
Verified:
* admin tool bootstrap - issue [1943] is NOT present
* Spark is able to resolve --packages
org.apache.polaris:polaris-spark-3.5_2.12:1.0.0-incubating
Spark Client deps are much cleaner now:
org.apache.po
Here's a PR to implement what was discussed in this thread. Please review:
https://github.com/apache/polaris/pull/1952
Cheers,
Dmitri.
On Mon, May 19, 2025 at 5:54 AM Robert Stupp wrote:
> +1 on having a CHANGELOG. That's been proven to be very useful.
>
> Change-log and release-notes (as a li
Thanks Russell. I don't have a better idea than brute force pattern
matching deletion. I'm OK with the approach in
https://github.com/apache/polaris/pull/1950.
Yufei
On Thu, Jun 26, 2025 at 12:38 PM yun zou wrote:
> Hi Russel,
>
> Thanks a lot! I can follow up on this once I am back.
>
> Best
Hi Russel,
Thanks a lot! I can follow up on this once I am back.
Best Regards,
Yun
On Thu, Jun 26, 2025 at 12:37 PM Russell Spitzer
wrote:
> PR Fixing up the license issue in the Spark Client Jar -
> https://github.com/apache/polaris/pull/1950
> I wasn't able to get the Shadow Jar to do it wit
PR Fixing up the license issue in the Spark Client Jar -
https://github.com/apache/polaris/pull/1950
I wasn'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 r
Some good news to share, I've figured out what should be included in
helm-chart/index.yaml for every new release, and updated here,
https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/index.yaml
.
Here are 3 steps to verify published Helm Chart in our staging repo:
> helm repo ad
Per our discussion during the community sync-up, we’ll continue verifying
RC2 while simultaneously working on a fix for the Spark Client multiple
license issue. Thanks Russell for picking it up!
If RC2 passes today or tomorrow and the fix is ready, we’ll cut a new
release candidate (RC3) that inclu
Thanks for the validation, Dmitri! Great to know that the 1.0.x branch
wasn't impacted. I'd suggest not backporting the fix given it's not broken
to avoid any other implications.
Yufei
On Wed, Jun 25, 2025 at 3:42 PM Dmitri Bourlatchkov
wrote:
> Update: I tested RC0 and it did NOT have this pr
>
> The diffs of PR 1695 [1] merged to "main" and the corresponding commit
> [2] on the 1.0.x branch are different for a GH workflow.
There was a minor difference due to the Python Client CI change in the file
python-client.yml that isn't in the 1.0.x branch. It won't impact any other
places and i
Hi all,
Thanks Adnan for the definition of read-based events – it wasn't clear for me.
> Adding a before and after event as part of a DB transaction isn't really
> useful - we should reduce to just one event emitted after.
Indeed, in this case the events table would look more like a CDC
commit
12 matches
Mail list logo
