Re: [DISCUSS] Prepare for 1.0 Release

RNs LGTM. Thanks, Yufei! Cheers, Dmitri. On Tue, Jul 8, 2025 at 8:41 PM Yufei Gu wrote: > 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 afte

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

Re: [DISCUSS] Prepare for 1.0 Release

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

Re: [DISCUSS] Prepare for 1.0 Release

Update: I tested RC0 and it did NOT have this problem. The problem appears to exist only on `main`. The fix in [1945] makes sense in general, though. I'll leave the backport decision to you, Yufei. I guess we'll have to retest with RC1 in any case. [1945] https://github.com/apache/polaris/pull/

Re: [DISCUSS] Prepare for 1.0 Release

Agreed! We also need to change the server side config in that case. Yufei On Wed, Jun 25, 2025 at 3:32 PM Dmitri Bourlatchkov wrote: > Hi Yufei, > > I've just tested the admin tool locally and it does fail with "No bean > found for required type [interface javax.sql.DataSource]" on the current

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, I've just tested the admin tool locally and it does fail with "No bean found for required type [interface javax.sql.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

Re: [DISCUSS] Prepare for 1.0 Release

Thanks for raising this, Dmitri! One minor question, does this( https://github.com/apache/polaris/pull/1945/files#r2167723808) affect normal use cases beside Quick Start? If that's the case, we could have it in the 1.0.0 release. Yufei On Wed, Jun 25, 2025 at 2:57 PM Dmitri Bourlatchkov wrote:

Re: [DISCUSS] Prepare for 1.0 Release

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! Sent out the 1.0.0 RC0 release > vote mail! > > Yufei > > > On Mon, Jun 23

Re: [DISCUSS] Prepare for 1.0 Release

+1 on the 1.0 release. I have verified manually with the spark client package use case with the current maven repo, I was able to create/insert/drop iceberg and delta table as expected. Best Regards, Yun On Mon, Jun 23, 2025 at 6:32 PM Yufei Gu wrote: > Thanks a lot for everyone working on thi

Re: [DISCUSS] Prepare for 1.0 Release

Thanks a lot for everyone working on this! Sent out the 1.0.0 RC0 release vote mail! Yufei On Mon, Jun 23, 2025 at 6:27 AM Dmitri Bourlatchkov wrote: > Re: 1: We have PR [1908], but no issue AFAIK. > > [1908] https://github.com/apache/polaris/pull/1908 > > Cheers, > Dmitri. > > On Mon, Jun 23,

Re: [DISCUSS] Prepare for 1.0 Release

Re: 1: We have PR [1908], but no issue AFAIK. [1908] https://github.com/apache/polaris/pull/1908 Cheers, Dmitri. On Mon, Jun 23, 2025 at 9:12 AM Jean-Baptiste Onofré wrote: > Hi Robert > > Yes, 1 has to be sorted out before the release. Do we have an issue > about that (beyond the thread discu

Re: [DISCUSS] Prepare for 1.0 Release

Hi Robert Yes, 1 has to be sorted out before the release. Do we have an issue about that (beyond the thread discussion) ? I already mentioned my "concern" about the shadow jar in Spark client. It's important but it can be improved later. The Maven coordinates are more problematic (if we change lat

Re: [DISCUSS] Prepare for 1.0 Release

Not "labeled" as blockers, but two things to clarify: 1. The "[DISCUSS[ Spark Client jars: maven coordinates and shading" thread 2. Having the docs for a release appear in a URL containing "in-dev" doesn't feel right. The first one might have implications to the release? On 23.06.25 13:30,

Re: [DISCUSS] Prepare for 1.0 Release

Hi folks, I don't see any Issue or PR with the 1.0-blocker label. I guess we are ready to cut 1.0.0 right ? Regards JB On Fri, Jun 20, 2025 at 8:12 PM Yufei Gu wrote: > > +1 on documenting on the site, which I don't think it's a 1.0 blocker. It's > been added into the release notes[1]. > > [1]

Re: [DISCUSS] Prepare for 1.0 Release

+1 on documenting on the site, which I don't think it's a 1.0 blocker. It's been added into the release notes[1]. [1]. https://docs.google.com/document/d/1JDVdQraoEhOIv7agy7WzIuBQdW0_16jW-DBrnanuW7A/edit?tab=t.0 Yufei On Fri, Jun 20, 2025 at 11:08 AM Dmitri Bourlatchkov wrote: > Thanks for th

Re: [DISCUSS] Prepare for 1.0 Release

Thanks for the heads up, Prashant! I agree that it was a good idea to pull Compaction Rollback into 1.0. Do we want to document this feature, or just mention it in release notes? Cheers, Dmitri. On Fri, Jun 20, 2025 at 1:17 PM Prashant Singh wrote: > Hey folks, > I want to thank the whole com

Re: [DISCUSS] Prepare for 1.0 Release

Hey folks, I want to thank the whole community for jumping in for the reviews of Rollback Compaction on conflicts feature here . I am happy to share that it has now merged, since the 1.0 boat has not sailed, I cherr

Re: [DISCUSS] Prepare for 1.0 Release

Hi All, Posting here for visibility: https://lists.apache.org/thread/0z30f3cfvm41hxlbxgp4fqdpv7mfgnv8 I opened that discussion thread about the new Spark Client plugin. My concern is that the linked PR looks like it may require changing out approach to how we publish Maven artifacts for that clie

Re: [DISCUSS] Prepare for 1.0 Release

Thanks ! It looks good to me. Regards JB Le jeu. 19 juin 2025 à 00:12, Yufei Gu a écrit : > The rename commits( > > https://github.com/apache/polaris/commit/ab228afa4d975faabb7aaf1e8abb0804f5b9d353 > and > > https://github.com/apache/polaris/commit/fccc51ab111b7ee1a0d3c8898e94b0c54bc73d80 > ) >

Re: [DISCUSS] Prepare for 1.0 Release

The rename commits( https://github.com/apache/polaris/commit/ab228afa4d975faabb7aaf1e8abb0804f5b9d353 and https://github.com/apache/polaris/commit/fccc51ab111b7ee1a0d3c8898e94b0c54bc73d80) have been cherry-picked to 1.0 branch. Yufei On Wed, Jun 18, 2025 at 2:51 PM Yufei Gu wrote: > We could r

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, As discussed before, I think it is preferable to do the renames in / before 1.0 because module names affect published Maven artifact names. For that matter, why not re-branch release/1.0.x from `main`? Thanks, Dmitri. On Wed, Jun 18, 2025 at 5:37 PM Yufei Gu wrote: > Hi JB and Dmitr

Re: [DISCUSS] Prepare for 1.0 Release

We could re-branch, but folks mentioned there are a few Python commits(like https://github.com/apache/polaris/pull/1810) we are not comfortable with having them in 1.0 branch. Feel free to bring up a discussion for more PRs you think it's 1.0 blockers and needed in 1.0. Yufei On Wed, Jun 18, 20

Re: [DISCUSS] Prepare for 1.0 Release

Hi JB and Dmitri, do we need https://github.com/apache/polaris/pull/1695 in 1.0? We used to agree on bringing it to 1.0 if it's ready, but I'm OK with either way. Yufei On Wed, Jun 18, 2025 at 2:31 PM Yufei Gu wrote: > https://github.com/apache/polaris/issues/1616 was resolved by #1830, > #183

Re: [DISCUSS] Prepare for 1.0 Release

https://github.com/apache/polaris/issues/1616 was resolved by #1830, #1834 and #1839. And these three commits are cherry-picked to 1.0 branch already. https://github.com/apache/polaris/issues/1881 was just resolved by #1889, which has been cherry-picked to 1.0 branch. Yufei On Wed, Jun 18, 2025

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, et al. It looks like only two 1.0 blockers remain: [1] https://github.com/apache/polaris/issues/1616 [2] https://github.com/apache/polaris/issues/1881 Re: [1] is anybody actively working on it? Also, I believe a lot of relevant changes got merged recently... WDYT about re-branching `r

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, More broadly, I believe an effective and efficient open-source community should have more trust, less bureaucracy. We should try to minimize unnecessary processes. And as you’ve seen, by requiring consensus to remove a blocker, it logically follows that adding one should also require con

Re: [DISCUSS] Prepare for 1.0 Release

Not sure. Mean, those "-rcX" are be voted on. We do not push "-rcX" jars to Maven Central, but would push Docker images. It's also that it's not us who configure the users' renovate/dependabot ;) Which is actually my fear, that users get those rc-images although those are not officially release

Re: [DISCUSS] Prepare for 1.0 Release

For 1.0, it is crucial to give users a clear statement on the contents of 1.0. These two PRs are essential parts of this, so those are legit 1.0 blockers, even if those do not touch code. On 13.06.25 21:14, Dmitri Bourlatchkov wrote: Hi Yufei, I agree that we do not have consensus on the _con

Re: [DISCUSS] Prepare for 1.0 Release

> > My opinion is that the issues are critical, even though we do not have an > agreement on the "fixes" for those issues, yet. Thanks for sharing, but I respectfully disagree. This isn’t just about the “fixes”, the blocker label is meant to reflect the urgency and criticality of an issue, and in

Re: [DISCUSS] Prepare for 1.0 Release

FYI, we fixed a few script and doc issues this week for the branch release/1.0.x! Special thanks to Eric, Yun, William, Jonas and Prashant for going through each individual doc and script, testing them out, filing issues and fixing. You can find the whole list here, https://github.com/apache/polari

Re: [DISCUSS] Prepare for 1.0 Release

I'm OK with the consensus process. Can you explain why introducing a blocker doesn't need consensus? This is to have a community-wide acknowledgement whether the _issues_ represented by those PRs are not critical for 1.0. My opinion is that the issues are critical, even though we do not have an

Re: [DISCUSS] Prepare for 1.0 Release

Thanks for raising this, but I disagree on three fronts: - Neither 1889[1] nor 1890[2] introduces a functional gap that would prevent users from adopting 1.0. They document best-practice guidance we can safely refine post-GA. Holding the release hostage to docs or policy wording sets a

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, Certainly, here's the dedicated discussion thread for PR 1890: https://lists.apache.org/thread/c0sk6hmtz9l4vs0mjc21wvlpblqhgx7r Cheers, Dmitri. On Fri, Jun 13, 2025 at 12:52 PM Yufei Gu wrote: > Dimiri, > > Thanks a lot for driving this initiative[1]. Can you raise a separate dev >

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, I agree that we do not have consensus on the _contents_ of PRs 1889 and 1890. However, I believe the issues these PRs attempt to address are still 1.0 blockers in my opinion (arguments for that given in previous emails). I'd say removing the blocker label from them itself needs consens

Re: [DISCUSS] Prepare for 1.0 Release

Hi Robert, hi all, I do agree with you that we need to distinguish between nightlies and production-ready artifacts, mainly because these repositories will be fed by fairly diverse pipelines: nightly images will be provided by an automated pipeline with no guarantee whatsoever about the contents i

Re: [DISCUSS] Prepare for 1.0 Release

Hi Dmitri, We don't have a consensus on adding these two PRs as 1.0 blocker. Can you please drop the label? Let's discuss it first. I don't think they are 1.0 blockers, but open to suggestions. 1. https://github.com/apache/polaris/pull/1889 2. https://github.com/apache/polaris/pull/1890 Yufei

Re: [DISCUSS] Prepare for 1.0 Release

Dimiri, Thanks a lot for driving this initiative[1]. Can you raise a separate dev mail thread for this? I think this deserves a broad awareness. 1. https://github.com/apache/polaris/pull/1890 Yufei On Fri, Jun 13, 2025 at 4:53 AM Robert Stupp wrote: > I was thinking of how the Docker images

Re: [DISCUSS] Prepare for 1.0 Release

I was thinking of how the Docker images are being staged and eventually released. I know there was a dev-ML thread about this, but I think this topic is important for the 1.0 release, so raising it here. The release-guide doesn't mention images at all, so the process isn't clear. TL;DR of my r

Re: [DISCUSS] Prepare for 1.0 Release

Thanks for raising these questions! These are all thoughts that have quite an impact on several aspects: * Will there be 1.0.x releases? * If so, how long will 1.0.x be maintained? * Will 1.1 be based on 1.0 or main? * What if we put 2.x into the mix? There are even more "questions" to that - t

Re: [DISCUSS] Prepare for 1.0 Release

+1 on "1.0-blocker" for both 1889 + 1890 On 13.06.25 04:24, Dmitri Bourlatchkov wrote: As discussed in the community sync today, I opened PR [1890] to inform users about what to expect in terms of backward compatibility as the project evolves. I proactively marked it as 1.0 blocker because I'm

Re: [DISCUSS] Prepare for 1.0 Release

I agree that doing the renaming now (before the 1.0 release) is much much easier even if it'd be renamed in a following major release. I hear there are concerns about the current naming. The current name was chosen at that time to disambiguate the "Quarkus variant" from the previous one, which

Re: [DISCUSS] Prepare for 1.0 Release

As discussed in the community sync today, I opened PR [1890] to inform users about what to expect in terms of backward compatibility as the project evolves. I proactively marked it as 1.0 blocker because I'm not sure whether docs have to be merged before the release in order to be reflected in the

Re: [DISCUSS] Prepare for 1.0 Release

I've marked [1889] as a 1.0 blocker. Feel free to disagree :) My rationale: Polaris 1.0 is a binary release and will provide a platform for users to experiment with Generic Tables. It is important to set correct expectations about this feature in terms of functional scope, level of maturity, plans

Re: [DISCUSS] Prepare for 1.0 Release

Re: the server module rename [1695]: I see that the 1.0 blocker label was removed from it. I'm personally ok with not including it in 1.0.0. However, I'd prefer to include it if other people find it valuable too. My rationale: * The new module names are more natural and probably more intuitive t

Re: [DISCUSS] Prepare for 1.0 Release

>From my POV the "release/a.b.c" pattern for release branches is self-explanatory and has prior history in Polaris. If the release guilde is perceived as too vague on this topic, let's update the guide and keep the pattern. In that regard, we may want to discuss whether to use very versions speci

Re: [DISCUSS] Prepare for 1.0 Release

Delete the branch "1.0.x". I'm OK with the name "release/1.0.x", but I don't think the current release guideline[1] mentioned any mandatory branch name convention. The name "release/x.y.z" is part of an example. We should add that name convention to the guidelines. [1] https://polaris.apache.org/

Re: [DISCUSS] Prepare for 1.0 Release

Heads up: It's also documented in the release-guide via https://github.com/apache/polaris/pull/1539, not sure you saw it. That doc also mentions how to apply versions, create tags etc. On 12.06.25 19:41, Yufei Gu wrote: Thanks for the explanation. Created a new branch named "release/1.0.x" for

Re: [DISCUSS] Prepare for 1.0 Release

Thanks for the explanation. Created a new branch named "release/1.0.x" for the 1.0 release. I will delete "1.0.x" a bit later. Yufei On Thu, Jun 12, 2025 at 9:05 AM Robert Stupp wrote: > Not sure whether everybody followed how the releases were crafted. We > discussed the branch naming patte

Re: [DISCUSS] Prepare for 1.0 Release

Not sure whether everybody followed how the releases were crafted. We discussed the branch naming pattern before during community sync calls. There's also the draft PR 485 for semi-automatic releases that relies on the same naming pattern. To change that, we have to have a discussion on dev@ fi

Re: [DISCUSS] Prepare for 1.0 Release

Not sure I follow you (maybe you didn't reply to my message specifically :)). My proposal was just to call for 1.0 consensus. Are we good in what should be included ? About #1695, if no consensus, I'm fine to remove the 1.0-blocker label here (it was best effort, and can be done later). Regards

Re: [DISCUSS] Prepare for 1.0 Release

We didn't do that for 0.9 and 0.10 releases before cutting a branch. If you think that's a new process we need to follow, please open a new dev ML thread for discussion. the wrong branch name Can you explain why there is a wrong branch name? Where is this agreement recorded? Where is the agree

Re: [DISCUSS] Prepare for 1.0 Release

Hi folks Back from the other part of the pond :) I think we should have a clear consensus about 1.0 content. That’s why I invite everyone to flag issues and PRs with the 1.0-blocker label. I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker, we are good to start rc. We can

Re: [DISCUSS] Prepare for 1.0 Release

Agree with Dmitri. Having clear discussion subjects is crucial for the community to follow the right threads. I think we should only get to consensus about the particular thread topic and nothing else. Consensus in a community in general, at least in my opinion, is more than two people havin

Re: [DISCUSS] Prepare for 1.0 Release

I added a 1.0 blocker label to [1857]. I believe it is a critical usability fix for users of Generic Tables in Spark. [1857] https://github.com/apache/polaris/pull/1857 Cheers, Dmitri. On Thu, May 15, 2025 at 5:39 PM Yufei Gu wrote: > Hi folks, > > Many users have been asking about the Polari

Re: [DISCUSS] Prepare for 1.0 Release

Also the last PPMC member's agreement on thread[1] happened 5 days ago, which passed the lazy consensus window. But I agreed it's nice to conclude a thread. The consensus in that thread was to skip the 0.10.0 release. >From my POV an agreement to skip 0.10.0 does not mean that the scope for 1.0

Re: [DISCUSS] Prepare for 1.0 Release

Discussed multiple times with JB last Thursday(6/5/2025) and this Monday(6/9/2025), we agreed to consider it as a nice-to-have instead of a blocker. I'm sure none of JB's statements (even though I was not part of those meetings, IIRC) implied that the agreement is community-wide. The Apache Way

Re: [DISCUSS] Prepare for 1.0 Release

The branch name is "1.0.x". Where is this agreement recorded? Discussed multiple times with JB last Thursday(6/5/2025) and this Monday(6/9/2025), we agreed to consider it as a nice-to-have instead of a blocker. As a matter of best practice, given the previous related discussion thread > [1], it

Re: [DISCUSS] Prepare for 1.0 Release

I cut the 1.0.x branch yesterday morning. As a matter of best practice, given the previous related discussion thread [1], it would have been nice to conclude it with a message about starting the 1.0 release process before actually cutting the branch. [1] https://lists.apache.org/thread/8kx1mjg7h

Re: [DISCUSS] Prepare for 1.0 Release

> I cut the 1.0.x branch yesterday morning I do not see a "release/1.0.0" branch (which is a pattern used for previous releases). [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a best-to-have instead of a blocker per offline discussion, Where is this agreement recorded? As fo

Re: [DISCUSS] Prepare for 1.0 Release

Thanks everyone for the contribution. We've finally resolved all blockers[1]. I cut the 1.0.x branch yesterday morning. Will only cherry pick bug fixes and license related commits to this branch starting now. [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a best-to-have instead o

Re: [DISCUSS] Prepare for 1.0 Release

+1 to making 801 a blocker. Based on Alex's comments in 1799, it looks like the rotation is only happening in JdbcMetastoreManagerFactory? If so, I think we have a very simple fix in PR#1804 . --EM

Re: [DISCUSS] Prepare for 1.0 Release

I re-opened [801] and labelled it as 1.0 blocker. My rationale is that it is a degraded UX and in previous discussions on this issue the consensus was that "it should not happen". [801] https://github.com/apache/polaris/issues/801 Cheers, Dmitri. On Mon, Jun 2, 2025 at 5:22 PM Dmitri Bourlatchk

Re: [DISCUSS] Prepare for 1.0 Release

Hi All, I've just added [1775] to the list of 1.0 blockers. My rationale: * As discussed in [1758], current configuration lookup methods have a certain API skew. Some methods have PolarisCallContext parameters, others RealmContext. PolarisCallContext implies a certain realm ID (e.g. it includes

Re: [DISCUSS] Prepare for 1.0 Release

Hi folks, Great to see that we’ve resolved most of the 1.0 blockers — huge thanks to everyone who contributed! Here are a few remaining items: 1. #1616 – I believe JB is working on this. JB, could you confirm? 2. #1676

Re: [DISCUSS] Prepare for 1.0 Release

Hi folks, We made great progress on the 1.0 release! Some blocker issues are fixed, or closed to be fixed! > >- Task handling is incomplete (#774) > > > Eric will file a follow-up issue to make the drop-by-purge feature > disabled by default.

Re: [DISCUSS] Prepare for 1.0 Release

Thanks everyone for the productive discussion! We've made great progress on cleaning up the Polaris 1.0 blockers. Here’s a quick summary: - Add CI for Python code ( #1058), Need a volunteer to pick https://github.com/apache/polaris/pull/1096 up

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei Sorry if I was not clear in my previous email (too many flights and travels this week :)): I'm OK for a specific meeting for 1.0 (to discuss the "blocking" issues and propose a plan/update on the dev mailing list), my message is more "generally speaking". Thanks Regards JB On Fri, May 1

Re: [DISCUSS] Prepare for 1.0 Release

Thanks Dmitri for chiming #777 and #552! I agreed PR 1532 is needed in 1.0. I'm OK with either merge https://github.com/apache/polaris/pull/1566 first, or iterate on PR 1532. As I said in another email thread, adding an extra configure is not necessary, but I'm fine with it. I will remove the "Req

Re: [DISCUSS] Prepare for 1.0 Release

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 enabl

Re: [DISCUSS] Prepare for 1.0 Release

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 discuss

[DISCUSS] Prepare for 1.0 Release

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