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