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

Reply via email to