Hi Arun Thanks for the update.
I will start the release prep (gathering PR to consider, etc) today. I will send an update on the dev mailing list. Regards JB On Mon, Aug 18, 2025 at 9:09 PM Arun Suri <arun.s...@fivetran.com.invalid> wrote: > > 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/>
