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