Hi all, I’d like to request that PR #2197 <https://github.com/apache/polaris/pull/2197> be included in the upcoming *1.1.0* release.
This PR introduces the resetCredentials API along with integration tests, adding important functionality for managing principal credentials. It also helps users who are migrating from EclipseLink to the JDBC metastore by providing a smoother path forward. The changes are self-contained, tests are passing, and the risk of regression is minimal. Thanks for considering On Tue, Aug 12, 2025 at 11:06 PM Yufei Gu <flyrain...@gmail.com> wrote: > Hi Pierre, It's a great idea that either you becomes the release manager or > shadow others like JB. > > Yufei > > > On Tue, Aug 12, 2025 at 8:02 AM Pierre Laporte <pie...@pingtimeout.fr> > wrote: > > > Hi folks > > > > The more I work on release automation, the more I realize certain parts > are > > likely not described 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 <flyrain...@gmail.com> wrote: > > > > > Thanks for chiming in, JB. You're right, the discussion around Generic > > > Tables isn't necessarily tied to a specific release. That said, > aligning > > > its GA with a release still makes sense, as reflected in the roadmap. > > > > > > I've created the 1.1.0-blocker label. Feel free to apply it to any > > relevant > > > issues or PRs. > > > > > > Yufei > > > > > > > > > On Tue, Jul 29, 2025 at 8:36 PM Jean-Baptiste Onofré <j...@nanthrax.net> > > > wrote: > > > > > > > Yeah, agree. > > > > > > > > I think we have two separate discussions here: > > > > 1. This thread was initially about 1.1.0-incubating release proposal > > > > and adopt the monthly release pace > > > > 2. The discussion 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 > > > > JB > > > > > > > > On Tue, Jul 29, 2025 at 6:27 PM Yufei Gu <flyrain...@gmail.com> > wrote: > > > > > > > > > > Let’s not allow the monthly release cadence to get in the way of > > > > > high-impact conversations, like re-evaluating the status of generic > > > > tables. > > > > > Remember how we all knew the community needed 1.0, but we kept > piling > > > on > > > > > blockers? A release only matters if it actually delivers value to > > > users. > > > > > > > > > > Absolutely keep tagging anything that’s truly a 1.1.0 blocker, for > > > > example, > > > > > things that would break the build or create serious regressions. > But > > > > let’s > > > > > treat the milestone label as a best-effort goal, not a gate. > > > > > > > > > > Yufei > > > > > > > > > > > > > > > On Tue, Jul 29, 2025 at 8:31 AM Dmitri Bourlatchkov < > > di...@apache.org> > > > > > wrote: > > > > > > > > > > > From my POV the "1.1.0" milestone works just as well and causes > > less > > > > > > agitation than a "blocker" label :) > > > > > > > > > > > > We can use it for collecting work items for a release. Whether > > > > something is > > > > > > a blocker probably needs to be discussed on the dev ML anyway. > > > > > > > > > > > > Cheers, > > > > > > Dmitri. > > > > > > > > > > > > On Tue, Jul 29, 2025 at 9:13 AM Eric Maynard < > > > eric.w.mayn...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > As far as this thread is concerned, what does everyone think > > about > > > > just > > > > > > > using a 1.1.0-blocker label similar to the one we had for 1.0 > and > > > > > > treating > > > > > > > that as the source of truth? > > > > > > > > > > > > > > If we take that approach, we can hash out the status of some > > change > > > > to > > > > > > > generic tables as a release blocker on the relevant issue or > > > mailing > > > > list > > > > > > > thread. > > > > > > > > > > > > > > —EM > > > > > > > > > > > > > > On Tue, Jul 29, 2025 at 21:55 Jean-Baptiste Onofré < > > > j...@nanthrax.net> > > > > > > > wrote: > > > > > > > > > > > > > > > By the way, specifically about Generic Tables I would still > > keep > > > > it as > > > > > > > > experimental for the following reasons: > > > > > > > > 1. We would need more feedback from the community to both > > > evaluate > > > > > > > > it's an interesting feature (from community standpoint) and > it > > > > works > > > > > > > > as the community expects > > > > > > > > 2. Generic table has been included in 1.0.0, I think would > > > > consider at > > > > > > > > least a couple of features (due to the first point) before > > > > considering > > > > > > > > as non experimental feature. So probably 1.2.0 (e.g. > September > > > > > > > > release) would be a good time to evaluate Generic Table (also > > > with > > > > the > > > > > > > > help of the community). > > > > > > > > 3. Very selfish :), I have a new proposal that I plan to > submit > > > > soon > > > > > > > > that could be a good "complement" of Generic Table. > > > > > > > > > > > > > > > > Just my $0.01 :) > > > > > > > > > > > > > > > > Regards > > > > > > > > JB > > > > > > > > > > > > > > > > On Tue, Jul 29, 2025 at 1:00 PM Jean-Baptiste Onofré < > > > > j...@nanthrax.net> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Yeah you are right. It’s probably feature per feature. A > > > > discussion > > > > > > on > > > > > > > > dev can happen to remove the experiment flag. My point is > that > > > > it’s not > > > > > > > > related to a release: as soon as the discussion happens and > > > > > > experimental > > > > > > > > flag is removed it will be included in the next release > > > (monthly). > > > > > > > > > > > > > > > > > > Wdyt ? > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > JB > > > > > > > > > > > > > > > > > > Le mar. 29 juil. 2025 à 11:40, Eric Maynard < > > > > > > eric.w.mayn...@gmail.com> > > > > > > > > a écrit : > > > > > > > > >> > > > > > > > > >> I agree with everything you said JB, but I’m not that it > > > > addresses > > > > > > the > > > > > > > > >> question around generic tables and the experimental label. > > In > > > > the > > > > > > case > > > > > > > > of > > > > > > > > >> generic tables the feature is already in 1.0. It will be > in > > > > 1.1.0. > > > > > > > > >> > > > > > > > > >> However we are labeling it “experimental” and the question > > > here > > > > is > > > > > > > about > > > > > > > > >> under what conditions that label will be removed. Is it > some > > > > number > > > > > > of > > > > > > > > >> releases? A vote? > > > > > > > > >> > > > > > > > > >> We should clarify this process, as right now it seems > rather > > > > > > > arbitrary. > > > > > > > > It > > > > > > > > >> appears that there is at least some tenuous connection to > > > > releases > > > > > > in > > > > > > > > the > > > > > > > > >> minds of some community members, as this labeling of the > > > > feature as > > > > > > > > >> experimental was reported to be a 1.0 blocker. > > > > > > > > >> > > > > > > > > >> —EM > > > > > > > > >> > > > > > > > > >> On Tue, Jul 29, 2025 at 13:37 Jean-Baptiste Onofré < > > > > j...@nanthrax.net > > > > > > > > > > > > > > > wrote: > > > > > > > > >> > > > > > > > > >> > Hi > > > > > > > > >> > > > > > > > > > >> > As we plan a monthly release pace now, I think we should > > use > > > > “best > > > > > > > > effort” > > > > > > > > >> > about what’s included in a release. If it’s not in this > > > month > > > > > > > release > > > > > > > > it > > > > > > > > >> > can included in next month one. > > > > > > > > >> > It means that I plan 1.2.0 in September, 1.3.0 in > October, > > > > etc. > > > > > > IMHO > > > > > > > > we > > > > > > > > >> > should remove the target release number from roadmap gh > > > > discussion > > > > > > > and > > > > > > > > >> > 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 > > > > > > > > >> > a dedicated meeting will help much. Instead I propose we > > > > update > > > > > > the > > > > > > > > >> > issues/PRs with target milestone, and if not done at > > release > > > > date, > > > > > > > we > > > > > > > > >> > postpone to next month release. > > > > > > > > >> > > > > > > > > > >> > The purpose is to not being too ambitious in terms of > > what’s > > > > > > > included > > > > > > > > but > > > > > > > > >> > have more frequent and predictable release dates for our > > > > users. > > > > > > > > >> > > > > > > > > > >> > Thoughts ? > > > > > > > > >> > > > > > > > > > >> > Regards > > > > > > > > >> > JB > > > > > > > > >> > > > > > > > > > >> > Le mar. 29 juil. 2025 à 00:14, Dmitri Bourlatchkov < > > > > > > > di...@apache.org> > > > > > > > > a > > > > > > > > >> > écrit : > > > > > > > > >> > > > > > > > > > >> > > Hi Yufei, > > > > > > > > >> > > > > > > > > > > >> > > > Can you elaborate on it? > > > > > > > > >> > > > > > > > > > > >> > > I proposed discussing (and elaborating on arguments > > about) > > > > the > > > > > > > > Generic > > > > > > > > >> > > Tables API in a separate thread. > > > > > > > > >> > > > > > > > > > > >> > > Cheers, > > > > > > > > >> > > Dmitri. > > > > > > > > >> > > > > > > > > > > >> > > On Mon, Jul 28, 2025 at 5:06 PM Yufei Gu < > > > > flyrain...@gmail.com> > > > > > > > > wrote: > > > > > > > > >> > > > > > > > > > > >> > > > Hi Dmitri, > > > > > > > > >> > > > > > > > > > > > >> > > > Thanks for chiming in. Are there any volunteers to > > work > > > on > > > > > > Helm > > > > > > > > chart > > > > > > > > >> > > > separation and CLI client publishing? > > > > > > > > >> > > > > > > > > > > > >> > > > > The related use cases and the future of them are > > still > > > > not > > > > > > > clear > > > > > > > > >> > > > > > > > > > > > >> > > > Can you elaborate on it? The Delta table use case is > > > > pretty > > > > > > > clear > > > > > > > > to me > > > > > > > > >> > > > that Polaris can host Delta tables and they are > > > accessible > > > > > > from > > > > > > > > Spark. > > > > > > > > >> > > > > > > > > > > > >> > > > Yufei > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > On Mon, Jul 28, 2025 at 1:56 PM Dmitri Bourlatchkov > < > > > > > > > > di...@apache.org> > > > > > > > > >> > > > wrote: > > > > > > > > >> > > > > > > > > > > > >> > > > > Hi Yufei, > > > > > > > > >> > > > > > > > > > > > > >> > > > > Re: Generic Tables API - I do not think it is > ready > > to > > > > be a > > > > > > > > standard > > > > > > > > >> > > > > feature in 1.1. The related use cases and the > future > > > of > > > > them > > > > > > > are > > > > > > > > >> > still > > > > > > > > >> > > > not > > > > > > > > >> > > > > clear, as far 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 at 3:12 PM Yufei Gu < > > > > > > > flyrain...@gmail.com> > > > > > > > > >> > wrote: > > > > > > > > >> > > > > > > > > > > > > >> > > > > > 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 > > > > > > > > decide > > > > > > > > >> > > > whether > > > > > > > > >> > > > > > the generic table feature and catalog > > federation > > > > should > > > > > > > be > > > > > > > > moved > > > > > > > > >> > > out > > > > > > > > >> > > > > of > > > > > > > > >> > > > > > preview. Personally, I’d like to see the > > generic > > > > table > > > > > > > > feature > > > > > > > > >> > > > > graduate > > > > > > > > >> > > > > > from preview. > > > > > > > > >> > > > > > - Helm Chart Repository & Release Strategy: I > > > > propose > > > > > > > > moving the > > > > > > > > >> > > > Helm > > > > > > > > >> > > > > > Chart to a separate repository and releasing > it > > > > > > > > independently. > > > > > > > > >> > > > > Ideally, > > > > > > > > >> > > > > > this should be in place by the 1.1.0 release. > > > > > > > > >> > > > > > - CLI Client Release: I’d like to include the > > CLI > > > > > > client > > > > > > > > within > > > > > > > > >> > > the > > > > > > > > >> > > > > > binary bundle and get it published along with > > 1.1 > > > > > > > release. > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > I'd also propose a dedicated community sync for > > the > > > > 1.1 > > > > > > > > release. > > > > > > > > >> > > > > Thoughts? > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > Yufei > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > On Fri, Jul 18, 2025 at 8:22 AM Dmitri > > Bourlatchkov > > > < > > > > > > > > >> > > di...@apache.org> > > > > > > > > >> > > > > > wrote: > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > A mid-August release sounds good to me. > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > I've added MinIO-related issues to the > > milestone: > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > * > https://github.com/apache/polaris/issues/1901 > > > > > > > > >> > > > > > > * > https://github.com/apache/polaris/issues/1530 > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > Cheers, > > > > > > > > >> > > > > > > Dmitri. > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > On Fri, Jul 18, 2025 at 1:07 AM Jean-Baptiste > > > > Onofré < > > > > > > > > >> > > > j...@nanthrax.net> > > > > > > > > >> > > > > > > wrote: > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > Hi folks, > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > I propose to have 1.1.0-incubating release > > > around > > > > > > August > > > > > > > > 20. > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > On github: > > > > > > > > >> > > > > > > > 1. I updated 1.1.0 milestone due date > > > > > > > > >> > > > > > > > 2. I will move the open issues still on > 1.0.0 > > > > > > milestone > > > > > > > to > > > > > > > > >> > 1.1.0 > > > > > > > > >> > > > > > > > 3. I will close the 1.0.0 milestone (as it > has > > > > been > > > > > > > > released) > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > My main focus is to review/update/improve > the > > > > release > > > > > > > > guide and > > > > > > > > >> > > > move > > > > > > > > >> > > > > > > > forward on semi-automatic release. > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > Thoughts ? > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > If you agree, feel free to create/assign > > issues > > > > for > > > > > > the > > > > > > > > 1.1.0 > > > > > > > > >> > > > > > milestone. > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > Thanks ! > > > > > > > > >> > > > > > > > Regards > > > > > > > > >> > > > > > > > JB > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Arun Suri Senior Software Engineer He/him/his Engineering | Fivetran arun.s...@fivetran.com fivetran.com <//fivetran.com> <http://www.fivetran.com> [image: facebook] <https://www.facebook.com/Fivetran/> [image: twitter] <https://twitter.com/fivetran?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor> [image: linkedin] <https://www.linkedin.com/company/fivetran> [image: instagram] <https://www.instagram.com/fivetran_ig/>
