You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by Dmitri Bourlatchkov <di...@apache.org> on 2025/06/02 21:22:55 UTC
Re: [DISCUSS] Prepare for 1.0 Release
Hi All,
I've just added [1775] to the list of 1.0 blockers. My rationale:
* As discussed in [1758], current configuration lookup methods have a
certain API skew.
Some methods have PolarisCallContext parameters, others
RealmContext. PolarisCallContext implies a certain realm ID (e.g. it
includes a BasePersistence, whose JDBC implementation is specific to a
realm - it has a realm ID field), but it does not expose the realm ID for
access to outside caller. As a result, this API makes it obscure how the
realm ID is obtained for looking up configuration values. Is it the
implicit realm ID in PolarisCallContext? Is it the realm ID from the
Request Scope?
* Given that some PRs and comments already bring up API backwards
compatibility concerns (e.g. [1724]), I believe it is critical to sort out
CDI context issues and configuration lookup APIs before 1.0 as it is a
central piece of Polaris backend and affects many code areas.
That said, I'm willing to participate in addressing [1175] ASAP.
[1724] https://github.com/apache/polaris/pull/1724
[1758] https://github.com/apache/polaris/pull/1758
[1775] https://github.com/apache/polaris/issues/1775
Cheers,
Dmitri.
On Thu, May 15, 2025 at 5:39 PM Yufei Gu <fl...@gmail.com> wrote:
> Hi folks,
>
> Many users have been asking about the Polaris release, and I believe it's
> critical to have a formal, production-ready 1.0 release ASAP. Thanks to the
> community’s hard work, we’re very close with a few remaining blockers we
> need to resolve.
>
> To keep things moving, I scheduled a community meeting for the 1.0 release
> next Monday at 9 AM PST. At the same time, sharing all issues marked with
> 1.0 blocker. We could resolve them here if possible. Feel free to chime in,
> remove the blocker tag if you think it's not a blocker, or pick any up.
> Thanks a lot in advance!
>
> Here is the list:
>
> - Add CI for Python code (
> <https://github.com/apache/polaris/issues/1058>#1058),
> - Polaris persistence concurrency issues (#777)
> <https://github.com/apache/polaris/issues/777>
> - Task handling is incomplete (#774)
> <https://github.com/apache/polaris/issues/774>
> - Generated files in regtests/client/python/polaris (#755)
> <https://github.com/apache/polaris/issues/755>
> - Resources not properly closed, resource & memory leaks (#563)
> <https://github.com/apache/polaris/issues/563>
> - Make Polaris safe against certain unparseable locations (#552)
> <https://github.com/apache/polaris/issues/552>
> - [BUG] Assumption that cache eviction does not happen (#544)
> <https://github.com/apache/polaris/issues/544>
>
> To make it more interactive, you can also comment on the google
> spreadsheet here:
>
> https://docs.google.com/spreadsheets/d/1GyLvp2cdYwioOsBwszNWiphZt_IIdo4LIfsZBFV88mc/edit?usp=sharing
>
> Yufei
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Robert Stupp <sn...@snazy.de>.
I agree that doing the renaming now (before the 1.0 release) is much
much easier even if it'd be renamed in a following major release.
I hear there are concerns about the current naming. The current name was
chosen at that time to disambiguate the "Quarkus variant" from the
previous one, which existed in parallel in the code base. IIRC there was
consensus at that time to rename it once the previous one is gone.
The current server artifact name reads "polaris-quarkus-server", which
raises the question: "Is there another server?" (the answer is: "Nope").
Anecdotally, in Nessie we have the same problem, but could never rename
it, just because there are way too many downstream dependencies.
Considering that, I revert my statement from yesterday's community sync
and think that we should rename now or never.
I'm +1 on renaming and use the opportunity and restart the "nomenclature
arguing dance" and propose:
* `polaris-server` for the current `polaris-quarkus-server`
* `polaris-admin-tool` for the current `polaris-quarkus-admin`
"runtime" is IMHO superfluous - a "server" is actually always a "runtime
thing", similar for the "admin tool".
How the directory structure looks like is a 2nd-ary question as it
doesn't affect the distributed artifacts - so "runtime" is okay for me
there.
Robert
On 13.06.25 02:05, Dmitri Bourlatchkov wrote:
> Re: the server module rename [1695]:
>
> I see that the 1.0 blocker label was removed from it. I'm personally ok
> with not including it in 1.0.0.
>
> However, I'd prefer to include it if other people find it valuable too. My
> rationale:
>
> * The new module names are more natural and probably more intuitive to
> users and potential contributors.
>
> * The module names make their way to Maven repositories so any rename after
> the first binary release will be a burden (even if we do it in 2.0) both to
> Polaris and to downstream projects.
>
> The downside for including it now seems small: 1) re-applying the rename to
> the latest main (hopefully not difficult as there are no functional
> changes) 2) minor risk of breaking scripts or docker images. Note that this
> will hold even if we do the renaming later.
>
> I do not think this rename is going to slow the release process down
> considerably. The base release timeline has not been short in Polaris to
> begin with.
>
> [1695] https://github.com/apache/polaris/pull/1695
>
> Cheers,
> Dmitri.
>
> On Thu, Jun 12, 2025 at 11:58 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Not sure I follow you (maybe you didn't reply to my message specifically
>> :)).
>>
>> My proposal was just to call for 1.0 consensus. Are we good in what
>> should be included ?
>>
>> About #1695, if no consensus, I'm fine to remove the 1.0-blocker label
>> here (it was best effort, and can be done later).
>>
>> Regards
>> JB
>>
>> On Thu, Jun 12, 2025 at 5:48 PM Yufei Gu <fl...@gmail.com> wrote:
>>> We didn't do that for 0.9 and 0.10 releases before cutting a branch. If
>> you
>>> think that's a new process we need to follow, please open a new dev ML
>>> thread for discussion.
>>>
>>> the wrong branch name
>>>
>>>
>>> Can you explain why there is a wrong branch name?
>>>
>>> Where is this agreement recorded?
>>>
>>> Where is the agreement record of adding [1] as a 1.0 blocker? Can you
>> open
>>> a thread for that if there is not? It seems controversial now.
>>>
>>> [1] https://github.com/apache/polaris/pull/1695.
>>>
>>> Yufei
>>>
>>>
>>> On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> Hi folks
>>>>
>>>> Back from the other part of the pond :)
>>>>
>>>> I think we should have a clear consensus about
>>>> 1.0 content. That’s why I invite everyone to flag issues and PRs with
>> the
>>>> 1.0-blocker label.
>>>> I propose to do a review in 24h. As soon as we don’t have any
>> 1.0-blocker,
>>>> we are good to start rc.
>>>>
>>>> We can also chat about that during the community meeting today.
>>>>
>>>> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on
>> the
>>>> main branch mainly about license/notice etc).
>>>>
>>>> Thanks !
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
>>>>
>>>>> Agree with Dmitri.
>>>>>
>>>>> Having clear discussion subjects is crucial for the community to
>> follow
>>>>> the right threads. I think we should only get to consensus about the
>>>>> particular thread topic and nothing else.
>>>>>
>>>>> Consensus in a community in general, at least in my opinion, is more
>>>>> than two people having the same opinion.
>>>>>
>>>>> We should also be careful about giving everybody enough time, and
>>>>> consider weekends and potentially public regional holidays.
>>>>>
>>>>> Regarding the technical actions: The branch name doesn't comply with
>> the
>>>>> existing naming convention (the branch naming pattern that JB used),
>>>>> which is also required to later support semi-automatic releases
>>>>> (discussed a couple months ago during a community sync call).
>>>>>
>>>>> Considering that we do not seem to have a consensus on the content of
>>>>> the 1.0 release, there are still 1.0-blockers and the wrong branch
>> name,
>>>>> I strongly prefer do delete that branch.
>>>>>
>>>>> Regarding the release manager, I'm in favor of letting JB drive the
>>>>> release process to ensure that things go smooth.
>>>>>
>>>>> Related note: We already have quite a bunch of branches in the GH
>> repo
>>>>> whose meaning is not clear to me.
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
>>>>>> Also the
>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago,
>> which
>>>>> passed
>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>> thread.
>>>>>>
>>>>>> The consensus in that thread was to skip the 0.10.0 release.
>>>>>>
>>>>>> From my POV an agreement to skip 0.10.0 does not mean that the
>> scope
>>>> for
>>>>>> 1.0 is set and agreed upon.
>>>>>>
>>>>>> What I'm asking for is proactively engaging with the community
>> before
>>>>>> executing technical actions for a new release as opposed to
>> informing
>>>>> after
>>>>>> actions are taken.
>>>>>>
>>>>>> [1]
>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>> Thanks,
>>>>>> Dmitri.
>>>>>>
>>>>>> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
>> wrote:
>>>>>>> The branch name is "1.0.x".
>>>>>>>
>>>>>>> Where is this agreement recorded?
>>>>>>>
>>>>>>> Discussed multiple times with JB last Thursday(6/5/2025) and this
>>>>>>> Monday(6/9/2025), we agreed to consider it as a nice-to-have
>> instead
>>>> of
>>>>> a
>>>>>>> blocker.
>>>>>>>
>>>>>>> As a matter of best practice, given the previous related
>> discussion
>>>>> thread
>>>>>>>> [1], it would have been nice to conclude it with a message about
>>>>> starting
>>>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>>> We got consensus on thread[1]. The 1.0 release was also prepared
>> way
>>>>> before
>>>>>>> the thread. We will kick off 1.0 release even if 0.10 is not
>> canceled.
>>>>> JB
>>>>>>> and I discussed the parallel releasing option for both versions.
>> Also
>>>>> the
>>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago,
>> which
>>>>> passed
>>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>>>> thread.
>>>>>>> [1]
>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>> Yufei
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
>> dimas@apache.org
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I cut the 1.0.x branch yesterday morning.
>>>>>>>>
>>>>>>>>
>>>>>>>> As a matter of best practice, given the previous related
>> discussion
>>>>>>> thread
>>>>>>>> [1], it would have been nice to conclude it with a message about
>>>>> starting
>>>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>>>>
>>>>>>>> [1]
>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>>> Thanks,
>>>>>>>> Dmitri.
>>>>>>>>
>>>>>>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
>>>> wrote:
>>>>>>>>> Thanks everyone for the contribution. We've finally resolved all
>>>>>>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
>>>>> cherry
>>>>>>>>> pick bug fixes and license related commits to this branch
>> starting
>>>>> now.
>>>>>>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that
>> it's a
>>>>>>>>> best-to-have instead of a blocker per offline discussion,
>>>>>>>>> https://github.com/apache/polaris/pull/1695.
>>>>>>>>>
>>>>>>>>> Yufei
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
>>>> eric.w.maynard@gmail.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> +1 to making 801 a blocker.
>>>>>>>>>>
>>>>>>>>>> Based on Alex's comments in 1799, it looks like the rotation is
>>>> only
>>>>>>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we
>> have a
>>>>>>> very
>>>>>>>>>> simple fix in PR#1804 <
>> https://github.com/apache/polaris/pull/1804
>>>>> .
>>>>>>>>>> --EM
>>>>>>>>>>
>>>>> --
>>>>> Robert Stupp
>>>>> @snazy
>>>>>
>>>>>
--
Robert Stupp
@snazy
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <di...@apache.org>.
Re: the server module rename [1695]:
I see that the 1.0 blocker label was removed from it. I'm personally ok
with not including it in 1.0.0.
However, I'd prefer to include it if other people find it valuable too. My
rationale:
* The new module names are more natural and probably more intuitive to
users and potential contributors.
* The module names make their way to Maven repositories so any rename after
the first binary release will be a burden (even if we do it in 2.0) both to
Polaris and to downstream projects.
The downside for including it now seems small: 1) re-applying the rename to
the latest main (hopefully not difficult as there are no functional
changes) 2) minor risk of breaking scripts or docker images. Note that this
will hold even if we do the renaming later.
I do not think this rename is going to slow the release process down
considerably. The base release timeline has not been short in Polaris to
begin with.
[1695] https://github.com/apache/polaris/pull/1695
Cheers,
Dmitri.
On Thu, Jun 12, 2025 at 11:58 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Not sure I follow you (maybe you didn't reply to my message specifically
> :)).
>
> My proposal was just to call for 1.0 consensus. Are we good in what
> should be included ?
>
> About #1695, if no consensus, I'm fine to remove the 1.0-blocker label
> here (it was best effort, and can be done later).
>
> Regards
> JB
>
> On Thu, Jun 12, 2025 at 5:48 PM Yufei Gu <fl...@gmail.com> wrote:
> >
> > We didn't do that for 0.9 and 0.10 releases before cutting a branch. If
> you
> > think that's a new process we need to follow, please open a new dev ML
> > thread for discussion.
> >
> > the wrong branch name
> >
> >
> > Can you explain why there is a wrong branch name?
> >
> > Where is this agreement recorded?
> >
> > Where is the agreement record of adding [1] as a 1.0 blocker? Can you
> open
> > a thread for that if there is not? It seems controversial now.
> >
> > [1] https://github.com/apache/polaris/pull/1695.
> >
> > Yufei
> >
> >
> > On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> > > Hi folks
> > >
> > > Back from the other part of the pond :)
> > >
> > > I think we should have a clear consensus about
> > > 1.0 content. That’s why I invite everyone to flag issues and PRs with
> the
> > > 1.0-blocker label.
> > > I propose to do a review in 24h. As soon as we don’t have any
> 1.0-blocker,
> > > we are good to start rc.
> > >
> > > We can also chat about that during the community meeting today.
> > >
> > > If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on
> the
> > > main branch mainly about license/notice etc).
> > >
> > > Thanks !
> > >
> > > Regards
> > > JB
> > >
> > > Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
> > >
> > > > Agree with Dmitri.
> > > >
> > > > Having clear discussion subjects is crucial for the community to
> follow
> > > > the right threads. I think we should only get to consensus about the
> > > > particular thread topic and nothing else.
> > > >
> > > > Consensus in a community in general, at least in my opinion, is more
> > > > than two people having the same opinion.
> > > >
> > > > We should also be careful about giving everybody enough time, and
> > > > consider weekends and potentially public regional holidays.
> > > >
> > > > Regarding the technical actions: The branch name doesn't comply with
> the
> > > > existing naming convention (the branch naming pattern that JB used),
> > > > which is also required to later support semi-automatic releases
> > > > (discussed a couple months ago during a community sync call).
> > > >
> > > > Considering that we do not seem to have a consensus on the content of
> > > > the 1.0 release, there are still 1.0-blockers and the wrong branch
> name,
> > > > I strongly prefer do delete that branch.
> > > >
> > > > Regarding the release manager, I'm in favor of letting JB drive the
> > > > release process to ensure that things go smooth.
> > > >
> > > > Related note: We already have quite a bunch of branches in the GH
> repo
> > > > whose meaning is not clear to me.
> > > >
> > > > Robert
> > > >
> > > >
> > > > On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> > > > > Also the
> > > > > last PPMC member's agreement on thread[1] happened 5 days ago,
> which
> > > > passed
> > > > > the lazy consensus window. But I agreed it's nice to conclude a
> thread.
> > > > >
> > > > >
> > > > > The consensus in that thread was to skip the 0.10.0 release.
> > > > >
> > > > > From my POV an agreement to skip 0.10.0 does not mean that the
> scope
> > > for
> > > > > 1.0 is set and agreed upon.
> > > > >
> > > > > What I'm asking for is proactively engaging with the community
> before
> > > > > executing technical actions for a new release as opposed to
> informing
> > > > after
> > > > > actions are taken.
> > > > >
> > > > > [1]
> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > > > >
> > > > > Thanks,
> > > > > Dmitri.
> > > > >
> > > > > On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
> wrote:
> > > > >
> > > > >> The branch name is "1.0.x".
> > > > >>
> > > > >> Where is this agreement recorded?
> > > > >>
> > > > >> Discussed multiple times with JB last Thursday(6/5/2025) and this
> > > > >> Monday(6/9/2025), we agreed to consider it as a nice-to-have
> instead
> > > of
> > > > a
> > > > >> blocker.
> > > > >>
> > > > >> As a matter of best practice, given the previous related
> discussion
> > > > thread
> > > > >>> [1], it would have been nice to conclude it with a message about
> > > > starting
> > > > >>> the 1.0 release process before actually cutting the branch.
> > > > >> We got consensus on thread[1]. The 1.0 release was also prepared
> way
> > > > before
> > > > >> the thread. We will kick off 1.0 release even if 0.10 is not
> canceled.
> > > > JB
> > > > >> and I discussed the parallel releasing option for both versions.
> Also
> > > > the
> > > > >> last PPMC member's agreement on thread[1] happened 5 days ago,
> which
> > > > passed
> > > > >> the lazy consensus window. But I agreed it's nice to conclude a
> > > thread.
> > > > >>
> > > > >> [1]
> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > > > >>
> > > > >> Yufei
> > > > >>
> > > > >>
> > > > >> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
> dimas@apache.org
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>> I cut the 1.0.x branch yesterday morning.
> > > > >>>
> > > > >>>
> > > > >>> As a matter of best practice, given the previous related
> discussion
> > > > >> thread
> > > > >>> [1], it would have been nice to conclude it with a message about
> > > > starting
> > > > >>> the 1.0 release process before actually cutting the branch.
> > > > >>>
> > > > >>> [1]
> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Dmitri.
> > > > >>>
> > > > >>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
> > > wrote:
> > > > >>>
> > > > >>>> Thanks everyone for the contribution. We've finally resolved all
> > > > >>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
> > > > cherry
> > > > >>>> pick bug fixes and license related commits to this branch
> starting
> > > > now.
> > > > >>>>
> > > > >>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that
> it's a
> > > > >>>> best-to-have instead of a blocker per offline discussion,
> > > > >>>> https://github.com/apache/polaris/pull/1695.
> > > > >>>>
> > > > >>>> Yufei
> > > > >>>>
> > > > >>>>
> > > > >>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
> > > eric.w.maynard@gmail.com
> > > > >
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> +1 to making 801 a blocker.
> > > > >>>>>
> > > > >>>>> Based on Alex's comments in 1799, it looks like the rotation is
> > > only
> > > > >>>>> happening in JdbcMetastoreManagerFactory? If so, I think we
> have a
> > > > >> very
> > > > >>>>> simple fix in PR#1804 <
> https://github.com/apache/polaris/pull/1804
> > > >.
> > > > >>>>>
> > > > >>>>> --EM
> > > > >>>>>
> > > > --
> > > > Robert Stupp
> > > > @snazy
> > > >
> > > >
> > >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Not sure I follow you (maybe you didn't reply to my message specifically :)).
My proposal was just to call for 1.0 consensus. Are we good in what
should be included ?
About #1695, if no consensus, I'm fine to remove the 1.0-blocker label
here (it was best effort, and can be done later).
Regards
JB
On Thu, Jun 12, 2025 at 5:48 PM Yufei Gu <fl...@gmail.com> wrote:
>
> We didn't do that for 0.9 and 0.10 releases before cutting a branch. If you
> think that's a new process we need to follow, please open a new dev ML
> thread for discussion.
>
> the wrong branch name
>
>
> Can you explain why there is a wrong branch name?
>
> Where is this agreement recorded?
>
> Where is the agreement record of adding [1] as a 1.0 blocker? Can you open
> a thread for that if there is not? It seems controversial now.
>
> [1] https://github.com/apache/polaris/pull/1695.
>
> Yufei
>
>
> On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi folks
> >
> > Back from the other part of the pond :)
> >
> > I think we should have a clear consensus about
> > 1.0 content. That’s why I invite everyone to flag issues and PRs with the
> > 1.0-blocker label.
> > I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
> > we are good to start rc.
> >
> > We can also chat about that during the community meeting today.
> >
> > If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
> > main branch mainly about license/notice etc).
> >
> > Thanks !
> >
> > Regards
> > JB
> >
> > Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
> >
> > > Agree with Dmitri.
> > >
> > > Having clear discussion subjects is crucial for the community to follow
> > > the right threads. I think we should only get to consensus about the
> > > particular thread topic and nothing else.
> > >
> > > Consensus in a community in general, at least in my opinion, is more
> > > than two people having the same opinion.
> > >
> > > We should also be careful about giving everybody enough time, and
> > > consider weekends and potentially public regional holidays.
> > >
> > > Regarding the technical actions: The branch name doesn't comply with the
> > > existing naming convention (the branch naming pattern that JB used),
> > > which is also required to later support semi-automatic releases
> > > (discussed a couple months ago during a community sync call).
> > >
> > > Considering that we do not seem to have a consensus on the content of
> > > the 1.0 release, there are still 1.0-blockers and the wrong branch name,
> > > I strongly prefer do delete that branch.
> > >
> > > Regarding the release manager, I'm in favor of letting JB drive the
> > > release process to ensure that things go smooth.
> > >
> > > Related note: We already have quite a bunch of branches in the GH repo
> > > whose meaning is not clear to me.
> > >
> > > Robert
> > >
> > >
> > > On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> > > > Also the
> > > > last PPMC member's agreement on thread[1] happened 5 days ago, which
> > > passed
> > > > the lazy consensus window. But I agreed it's nice to conclude a thread.
> > > >
> > > >
> > > > The consensus in that thread was to skip the 0.10.0 release.
> > > >
> > > > From my POV an agreement to skip 0.10.0 does not mean that the scope
> > for
> > > > 1.0 is set and agreed upon.
> > > >
> > > > What I'm asking for is proactively engaging with the community before
> > > > executing technical actions for a new release as opposed to informing
> > > after
> > > > actions are taken.
> > > >
> > > > [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > > >
> > > > Thanks,
> > > > Dmitri.
> > > >
> > > > On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com> wrote:
> > > >
> > > >> The branch name is "1.0.x".
> > > >>
> > > >> Where is this agreement recorded?
> > > >>
> > > >> Discussed multiple times with JB last Thursday(6/5/2025) and this
> > > >> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
> > of
> > > a
> > > >> blocker.
> > > >>
> > > >> As a matter of best practice, given the previous related discussion
> > > thread
> > > >>> [1], it would have been nice to conclude it with a message about
> > > starting
> > > >>> the 1.0 release process before actually cutting the branch.
> > > >> We got consensus on thread[1]. The 1.0 release was also prepared way
> > > before
> > > >> the thread. We will kick off 1.0 release even if 0.10 is not canceled.
> > > JB
> > > >> and I discussed the parallel releasing option for both versions. Also
> > > the
> > > >> last PPMC member's agreement on thread[1] happened 5 days ago, which
> > > passed
> > > >> the lazy consensus window. But I agreed it's nice to conclude a
> > thread.
> > > >>
> > > >> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > > >>
> > > >> Yufei
> > > >>
> > > >>
> > > >> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <dimas@apache.org
> > >
> > > >> wrote:
> > > >>
> > > >>> I cut the 1.0.x branch yesterday morning.
> > > >>>
> > > >>>
> > > >>> As a matter of best practice, given the previous related discussion
> > > >> thread
> > > >>> [1], it would have been nice to conclude it with a message about
> > > starting
> > > >>> the 1.0 release process before actually cutting the branch.
> > > >>>
> > > >>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > > >>>
> > > >>> Thanks,
> > > >>> Dmitri.
> > > >>>
> > > >>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
> > wrote:
> > > >>>
> > > >>>> Thanks everyone for the contribution. We've finally resolved all
> > > >>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
> > > cherry
> > > >>>> pick bug fixes and license related commits to this branch starting
> > > now.
> > > >>>>
> > > >>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> > > >>>> best-to-have instead of a blocker per offline discussion,
> > > >>>> https://github.com/apache/polaris/pull/1695.
> > > >>>>
> > > >>>> Yufei
> > > >>>>
> > > >>>>
> > > >>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
> > eric.w.maynard@gmail.com
> > > >
> > > >>>> wrote:
> > > >>>>
> > > >>>>> +1 to making 801 a blocker.
> > > >>>>>
> > > >>>>> Based on Alex's comments in 1799, it looks like the rotation is
> > only
> > > >>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
> > > >> very
> > > >>>>> simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804
> > >.
> > > >>>>>
> > > >>>>> --EM
> > > >>>>>
> > > --
> > > Robert Stupp
> > > @snazy
> > >
> > >
> >
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Robert Stupp <sn...@snazy.de>.
Thanks for raising these questions!
These are all thoughts that have quite an impact on several aspects:
* Will there be 1.0.x releases?
* If so, how long will 1.0.x be maintained?
* Will 1.1 be based on 1.0 or main?
* What if we put 2.x into the mix?
There are even more "questions" to that - the combined result impacts
the name of the release branch, if it is needed, the web site and
potentially other aspects.
The "semi automated releases" draft-PR already considers different
answers to these questions. I.e. a branch is not required for a release
- release-branches and releases are orthogonal. All you technically need
for a release is a Git commit to create a release from.
On 13.06.25 01:51, Dmitri Bourlatchkov wrote:
> From my POV the "release/a.b.c" pattern for release branches is
> self-explanatory and has prior history in Polaris.
>
> If the release guilde is perceived as too vague on this topic, let's update
> the guide and keep the pattern.
>
> In that regard, we may want to discuss whether to use very versions
> specific branches like release/1.0.0 or use a branch per minor versions
> like release/1.0.x
>
> I'm personally fine with either approach.
>
> Another question: shall we tag after a release is approved and remove
> release branches?
>
> From my POV doing that would make sense so as to keep the set branches lean
> and clean (as discussed in a separate thread in a more general context). We
> can always re-create branches for point releases from the previous release
> tag. WDYT?
>
> Cheers,
> Dmitri.
>
> On Thu, Jun 12, 2025 at 4:55 PM Yufei Gu <fl...@gmail.com> wrote:
>
>> Delete the branch "1.0.x".
>>
>> I'm OK with the name "release/1.0.x", but I don't think the current release
>> guideline[1] mentioned any mandatory branch name convention. The name
>> "release/x.y.z" is part of an example. We should add that name convention
>> to the guidelines.
>>
>> [1] https://polaris.apache.org/community/release-guide/
>>
>> Yufei
>>
>>
>> On Thu, Jun 12, 2025 at 11:07 AM Robert Stupp <sn...@snazy.de> wrote:
>>
>>> Heads up: It's also documented in the release-guide via
>>> https://github.com/apache/polaris/pull/1539, not sure you saw it. That
>>> doc also mentions how to apply versions, create tags etc.
>>>
>>> On 12.06.25 19:41, Yufei Gu wrote:
>>>> Thanks for the explanation. Created a new branch named "release/1.0.x"
>>> for
>>>> the 1.0 release. I will delete "1.0.x" a bit later.
>>>>
>>>>
>>>> Yufei
>>>>
>>>>
>>>> On Thu, Jun 12, 2025 at 9:05 AM Robert Stupp <sn...@snazy.de> wrote:
>>>>
>>>>> Not sure whether everybody followed how the releases were crafted. We
>>>>> discussed the branch naming pattern before during community sync
>> calls.
>>>>> There's also the draft PR 485 for semi-automatic releases that relies
>> on
>>>>> the same naming pattern. To change that, we have to have a discussion
>> on
>>>>> dev@ first.
>>>>>
>>>>> 1695 is for me a legit 1.0-blocker, as it changes the artifact names
>>>>> that users may refer to - including downloadable binary distributions.
>>>>> Either we change it before 1.0 or not at all.
>>>>>
>>>>> PR 485: https://github.com/apache/polaris/pull/485
>>>>>
>>>>>
>>>>> On 12.06.25 17:48, Yufei Gu wrote:
>>>>>> We didn't do that for 0.9 and 0.10 releases before cutting a branch.
>> If
>>>>> you
>>>>>> think that's a new process we need to follow, please open a new dev
>> ML
>>>>>> thread for discussion.
>>>>>>
>>>>>> the wrong branch name
>>>>>>
>>>>>>
>>>>>> Can you explain why there is a wrong branch name?
>>>>>>
>>>>>> Where is this agreement recorded?
>>>>>>
>>>>>> Where is the agreement record of adding [1] as a 1.0 blocker? Can you
>>>>> open
>>>>>> a thread for that if there is not? It seems controversial now.
>>>>>>
>>>>>> [1] https://github.com/apache/polaris/pull/1695.
>>>>>>
>>>>>> Yufei
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <
>> jb@nanthrax.net>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi folks
>>>>>>>
>>>>>>> Back from the other part of the pond :)
>>>>>>>
>>>>>>> I think we should have a clear consensus about
>>>>>>> 1.0 content. That’s why I invite everyone to flag issues and PRs
>> with
>>>>> the
>>>>>>> 1.0-blocker label.
>>>>>>> I propose to do a review in 24h. As soon as we don’t have any
>>>>> 1.0-blocker,
>>>>>>> we are good to start rc.
>>>>>>>
>>>>>>> We can also chat about that during the community meeting today.
>>>>>>>
>>>>>>> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass
>> on
>>>>> the
>>>>>>> main branch mainly about license/notice etc).
>>>>>>>
>>>>>>> Thanks !
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a
>> écrit :
>>>>>>>> Agree with Dmitri.
>>>>>>>>
>>>>>>>> Having clear discussion subjects is crucial for the community to
>>> follow
>>>>>>>> the right threads. I think we should only get to consensus about
>> the
>>>>>>>> particular thread topic and nothing else.
>>>>>>>>
>>>>>>>> Consensus in a community in general, at least in my opinion, is
>> more
>>>>>>>> than two people having the same opinion.
>>>>>>>>
>>>>>>>> We should also be careful about giving everybody enough time, and
>>>>>>>> consider weekends and potentially public regional holidays.
>>>>>>>>
>>>>>>>> Regarding the technical actions: The branch name doesn't comply
>> with
>>>>> the
>>>>>>>> existing naming convention (the branch naming pattern that JB
>> used),
>>>>>>>> which is also required to later support semi-automatic releases
>>>>>>>> (discussed a couple months ago during a community sync call).
>>>>>>>>
>>>>>>>> Considering that we do not seem to have a consensus on the content
>> of
>>>>>>>> the 1.0 release, there are still 1.0-blockers and the wrong branch
>>>>> name,
>>>>>>>> I strongly prefer do delete that branch.
>>>>>>>>
>>>>>>>> Regarding the release manager, I'm in favor of letting JB drive the
>>>>>>>> release process to ensure that things go smooth.
>>>>>>>>
>>>>>>>> Related note: We already have quite a bunch of branches in the GH
>>> repo
>>>>>>>> whose meaning is not clear to me.
>>>>>>>>
>>>>>>>> Robert
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
>>>>>>>>> Also the
>>>>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago,
>> which
>>>>>>>> passed
>>>>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>>>>> thread.
>>>>>>>>> The consensus in that thread was to skip the 0.10.0 release.
>>>>>>>>>
>>>>>>>>> From my POV an agreement to skip 0.10.0 does not mean that the
>>> scope
>>>>>>> for
>>>>>>>>> 1.0 is set and agreed upon.
>>>>>>>>>
>>>>>>>>> What I'm asking for is proactively engaging with the community
>>> before
>>>>>>>>> executing technical actions for a new release as opposed to
>>> informing
>>>>>>>> after
>>>>>>>>> actions are taken.
>>>>>>>>>
>>>>>>>>> [1]
>>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>>>> Thanks,
>>>>>>>>> Dmitri.
>>>>>>>>>
>>>>>>>>> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
>>>>> wrote:
>>>>>>>>>> The branch name is "1.0.x".
>>>>>>>>>>
>>>>>>>>>> Where is this agreement recorded?
>>>>>>>>>>
>>>>>>>>>> Discussed multiple times with JB last Thursday(6/5/2025) and this
>>>>>>>>>> Monday(6/9/2025), we agreed to consider it as a nice-to-have
>>> instead
>>>>>>> of
>>>>>>>> a
>>>>>>>>>> blocker.
>>>>>>>>>>
>>>>>>>>>> As a matter of best practice, given the previous related
>> discussion
>>>>>>>> thread
>>>>>>>>>>> [1], it would have been nice to conclude it with a message about
>>>>>>>> starting
>>>>>>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>>>>>> We got consensus on thread[1]. The 1.0 release was also prepared
>>> way
>>>>>>>> before
>>>>>>>>>> the thread. We will kick off 1.0 release even if 0.10 is not
>>>>> canceled.
>>>>>>>> JB
>>>>>>>>>> and I discussed the parallel releasing option for both versions.
>>> Also
>>>>>>>> the
>>>>>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago,
>>> which
>>>>>>>> passed
>>>>>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>>>>>>> thread.
>>>>>>>>>> [1]
>>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>>>>> Yufei
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
>>>>> dimas@apache.org
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I cut the 1.0.x branch yesterday morning.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> As a matter of best practice, given the previous related
>>> discussion
>>>>>>>>>> thread
>>>>>>>>>>> [1], it would have been nice to conclude it with a message about
>>>>>>>> starting
>>>>>>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dmitri.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>> Thanks everyone for the contribution. We've finally resolved
>> all
>>>>>>>>>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will
>> only
>>>>>>>> cherry
>>>>>>>>>>>> pick bug fixes and license related commits to this branch
>>> starting
>>>>>>>> now.
>>>>>>>>>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that
>> it's
>>> a
>>>>>>>>>>>> best-to-have instead of a blocker per offline discussion,
>>>>>>>>>>>> https://github.com/apache/polaris/pull/1695.
>>>>>>>>>>>>
>>>>>>>>>>>> Yufei
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
>>>>>>> eric.w.maynard@gmail.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> +1 to making 801 a blocker.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Based on Alex's comments in 1799, it looks like the rotation
>> is
>>>>>>> only
>>>>>>>>>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we
>>> have a
>>>>>>>>>> very
>>>>>>>>>>>>> simple fix in PR#1804 <
>>>>> https://github.com/apache/polaris/pull/1804
>>>>>>>> .
>>>>>>>>>>>>> --EM
>>>>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Robert Stupp
>>>>>>>> @snazy
>>>>>>>>
>>>>>>>>
>>>>> --
>>>>> Robert Stupp
>>>>> @snazy
>>>>>
>>>>>
>>> --
>>> Robert Stupp
>>> @snazy
>>>
>>>
--
Robert Stupp
@snazy
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <di...@apache.org>.
From my POV the "release/a.b.c" pattern for release branches is
self-explanatory and has prior history in Polaris.
If the release guilde is perceived as too vague on this topic, let's update
the guide and keep the pattern.
In that regard, we may want to discuss whether to use very versions
specific branches like release/1.0.0 or use a branch per minor versions
like release/1.0.x
I'm personally fine with either approach.
Another question: shall we tag after a release is approved and remove
release branches?
From my POV doing that would make sense so as to keep the set branches lean
and clean (as discussed in a separate thread in a more general context). We
can always re-create branches for point releases from the previous release
tag. WDYT?
Cheers,
Dmitri.
On Thu, Jun 12, 2025 at 4:55 PM Yufei Gu <fl...@gmail.com> wrote:
> Delete the branch "1.0.x".
>
> I'm OK with the name "release/1.0.x", but I don't think the current release
> guideline[1] mentioned any mandatory branch name convention. The name
> "release/x.y.z" is part of an example. We should add that name convention
> to the guidelines.
>
> [1] https://polaris.apache.org/community/release-guide/
>
> Yufei
>
>
> On Thu, Jun 12, 2025 at 11:07 AM Robert Stupp <sn...@snazy.de> wrote:
>
> > Heads up: It's also documented in the release-guide via
> > https://github.com/apache/polaris/pull/1539, not sure you saw it. That
> > doc also mentions how to apply versions, create tags etc.
> >
> > On 12.06.25 19:41, Yufei Gu wrote:
> > > Thanks for the explanation. Created a new branch named "release/1.0.x"
> > for
> > > the 1.0 release. I will delete "1.0.x" a bit later.
> > >
> > >
> > > Yufei
> > >
> > >
> > > On Thu, Jun 12, 2025 at 9:05 AM Robert Stupp <sn...@snazy.de> wrote:
> > >
> > >> Not sure whether everybody followed how the releases were crafted. We
> > >> discussed the branch naming pattern before during community sync
> calls.
> > >> There's also the draft PR 485 for semi-automatic releases that relies
> on
> > >> the same naming pattern. To change that, we have to have a discussion
> on
> > >> dev@ first.
> > >>
> > >> 1695 is for me a legit 1.0-blocker, as it changes the artifact names
> > >> that users may refer to - including downloadable binary distributions.
> > >> Either we change it before 1.0 or not at all.
> > >>
> > >> PR 485: https://github.com/apache/polaris/pull/485
> > >>
> > >>
> > >> On 12.06.25 17:48, Yufei Gu wrote:
> > >>> We didn't do that for 0.9 and 0.10 releases before cutting a branch.
> If
> > >> you
> > >>> think that's a new process we need to follow, please open a new dev
> ML
> > >>> thread for discussion.
> > >>>
> > >>> the wrong branch name
> > >>>
> > >>>
> > >>> Can you explain why there is a wrong branch name?
> > >>>
> > >>> Where is this agreement recorded?
> > >>>
> > >>> Where is the agreement record of adding [1] as a 1.0 blocker? Can you
> > >> open
> > >>> a thread for that if there is not? It seems controversial now.
> > >>>
> > >>> [1] https://github.com/apache/polaris/pull/1695.
> > >>>
> > >>> Yufei
> > >>>
> > >>>
> > >>> On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <
> jb@nanthrax.net>
> > >>> wrote:
> > >>>
> > >>>> Hi folks
> > >>>>
> > >>>> Back from the other part of the pond :)
> > >>>>
> > >>>> I think we should have a clear consensus about
> > >>>> 1.0 content. That’s why I invite everyone to flag issues and PRs
> with
> > >> the
> > >>>> 1.0-blocker label.
> > >>>> I propose to do a review in 24h. As soon as we don’t have any
> > >> 1.0-blocker,
> > >>>> we are good to start rc.
> > >>>>
> > >>>> We can also chat about that during the community meeting today.
> > >>>>
> > >>>> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass
> on
> > >> the
> > >>>> main branch mainly about license/notice etc).
> > >>>>
> > >>>> Thanks !
> > >>>>
> > >>>> Regards
> > >>>> JB
> > >>>>
> > >>>> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a
> écrit :
> > >>>>
> > >>>>> Agree with Dmitri.
> > >>>>>
> > >>>>> Having clear discussion subjects is crucial for the community to
> > follow
> > >>>>> the right threads. I think we should only get to consensus about
> the
> > >>>>> particular thread topic and nothing else.
> > >>>>>
> > >>>>> Consensus in a community in general, at least in my opinion, is
> more
> > >>>>> than two people having the same opinion.
> > >>>>>
> > >>>>> We should also be careful about giving everybody enough time, and
> > >>>>> consider weekends and potentially public regional holidays.
> > >>>>>
> > >>>>> Regarding the technical actions: The branch name doesn't comply
> with
> > >> the
> > >>>>> existing naming convention (the branch naming pattern that JB
> used),
> > >>>>> which is also required to later support semi-automatic releases
> > >>>>> (discussed a couple months ago during a community sync call).
> > >>>>>
> > >>>>> Considering that we do not seem to have a consensus on the content
> of
> > >>>>> the 1.0 release, there are still 1.0-blockers and the wrong branch
> > >> name,
> > >>>>> I strongly prefer do delete that branch.
> > >>>>>
> > >>>>> Regarding the release manager, I'm in favor of letting JB drive the
> > >>>>> release process to ensure that things go smooth.
> > >>>>>
> > >>>>> Related note: We already have quite a bunch of branches in the GH
> > repo
> > >>>>> whose meaning is not clear to me.
> > >>>>>
> > >>>>> Robert
> > >>>>>
> > >>>>>
> > >>>>> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> > >>>>>> Also the
> > >>>>>> last PPMC member's agreement on thread[1] happened 5 days ago,
> which
> > >>>>> passed
> > >>>>>> the lazy consensus window. But I agreed it's nice to conclude a
> > >> thread.
> > >>>>>>
> > >>>>>> The consensus in that thread was to skip the 0.10.0 release.
> > >>>>>>
> > >>>>>> From my POV an agreement to skip 0.10.0 does not mean that the
> > scope
> > >>>> for
> > >>>>>> 1.0 is set and agreed upon.
> > >>>>>>
> > >>>>>> What I'm asking for is proactively engaging with the community
> > before
> > >>>>>> executing technical actions for a new release as opposed to
> > informing
> > >>>>> after
> > >>>>>> actions are taken.
> > >>>>>>
> > >>>>>> [1]
> > https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Dmitri.
> > >>>>>>
> > >>>>>> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
> > >> wrote:
> > >>>>>>> The branch name is "1.0.x".
> > >>>>>>>
> > >>>>>>> Where is this agreement recorded?
> > >>>>>>>
> > >>>>>>> Discussed multiple times with JB last Thursday(6/5/2025) and this
> > >>>>>>> Monday(6/9/2025), we agreed to consider it as a nice-to-have
> > instead
> > >>>> of
> > >>>>> a
> > >>>>>>> blocker.
> > >>>>>>>
> > >>>>>>> As a matter of best practice, given the previous related
> discussion
> > >>>>> thread
> > >>>>>>>> [1], it would have been nice to conclude it with a message about
> > >>>>> starting
> > >>>>>>>> the 1.0 release process before actually cutting the branch.
> > >>>>>>> We got consensus on thread[1]. The 1.0 release was also prepared
> > way
> > >>>>> before
> > >>>>>>> the thread. We will kick off 1.0 release even if 0.10 is not
> > >> canceled.
> > >>>>> JB
> > >>>>>>> and I discussed the parallel releasing option for both versions.
> > Also
> > >>>>> the
> > >>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago,
> > which
> > >>>>> passed
> > >>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
> > >>>> thread.
> > >>>>>>> [1]
> > https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >>>>>>>
> > >>>>>>> Yufei
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
> > >> dimas@apache.org
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> I cut the 1.0.x branch yesterday morning.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> As a matter of best practice, given the previous related
> > discussion
> > >>>>>>> thread
> > >>>>>>>> [1], it would have been nice to conclude it with a message about
> > >>>>> starting
> > >>>>>>>> the 1.0 release process before actually cutting the branch.
> > >>>>>>>>
> > >>>>>>>> [1]
> > >> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >>>>>>>> Thanks,
> > >>>>>>>> Dmitri.
> > >>>>>>>>
> > >>>>>>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
> > >>>> wrote:
> > >>>>>>>>> Thanks everyone for the contribution. We've finally resolved
> all
> > >>>>>>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will
> only
> > >>>>> cherry
> > >>>>>>>>> pick bug fixes and license related commits to this branch
> > starting
> > >>>>> now.
> > >>>>>>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that
> it's
> > a
> > >>>>>>>>> best-to-have instead of a blocker per offline discussion,
> > >>>>>>>>> https://github.com/apache/polaris/pull/1695.
> > >>>>>>>>>
> > >>>>>>>>> Yufei
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
> > >>>> eric.w.maynard@gmail.com
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> +1 to making 801 a blocker.
> > >>>>>>>>>>
> > >>>>>>>>>> Based on Alex's comments in 1799, it looks like the rotation
> is
> > >>>> only
> > >>>>>>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we
> > have a
> > >>>>>>> very
> > >>>>>>>>>> simple fix in PR#1804 <
> > >> https://github.com/apache/polaris/pull/1804
> > >>>>> .
> > >>>>>>>>>> --EM
> > >>>>>>>>>>
> > >>>>> --
> > >>>>> Robert Stupp
> > >>>>> @snazy
> > >>>>>
> > >>>>>
> > >> --
> > >> Robert Stupp
> > >> @snazy
> > >>
> > >>
> > --
> > Robert Stupp
> > @snazy
> >
> >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Yufei Gu <fl...@gmail.com>.
Delete the branch "1.0.x".
I'm OK with the name "release/1.0.x", but I don't think the current release
guideline[1] mentioned any mandatory branch name convention. The name
"release/x.y.z" is part of an example. We should add that name convention
to the guidelines.
[1] https://polaris.apache.org/community/release-guide/
Yufei
On Thu, Jun 12, 2025 at 11:07 AM Robert Stupp <sn...@snazy.de> wrote:
> Heads up: It's also documented in the release-guide via
> https://github.com/apache/polaris/pull/1539, not sure you saw it. That
> doc also mentions how to apply versions, create tags etc.
>
> On 12.06.25 19:41, Yufei Gu wrote:
> > Thanks for the explanation. Created a new branch named "release/1.0.x"
> for
> > the 1.0 release. I will delete "1.0.x" a bit later.
> >
> >
> > Yufei
> >
> >
> > On Thu, Jun 12, 2025 at 9:05 AM Robert Stupp <sn...@snazy.de> wrote:
> >
> >> Not sure whether everybody followed how the releases were crafted. We
> >> discussed the branch naming pattern before during community sync calls.
> >> There's also the draft PR 485 for semi-automatic releases that relies on
> >> the same naming pattern. To change that, we have to have a discussion on
> >> dev@ first.
> >>
> >> 1695 is for me a legit 1.0-blocker, as it changes the artifact names
> >> that users may refer to - including downloadable binary distributions.
> >> Either we change it before 1.0 or not at all.
> >>
> >> PR 485: https://github.com/apache/polaris/pull/485
> >>
> >>
> >> On 12.06.25 17:48, Yufei Gu wrote:
> >>> We didn't do that for 0.9 and 0.10 releases before cutting a branch. If
> >> you
> >>> think that's a new process we need to follow, please open a new dev ML
> >>> thread for discussion.
> >>>
> >>> the wrong branch name
> >>>
> >>>
> >>> Can you explain why there is a wrong branch name?
> >>>
> >>> Where is this agreement recorded?
> >>>
> >>> Where is the agreement record of adding [1] as a 1.0 blocker? Can you
> >> open
> >>> a thread for that if there is not? It seems controversial now.
> >>>
> >>> [1] https://github.com/apache/polaris/pull/1695.
> >>>
> >>> Yufei
> >>>
> >>>
> >>> On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>> wrote:
> >>>
> >>>> Hi folks
> >>>>
> >>>> Back from the other part of the pond :)
> >>>>
> >>>> I think we should have a clear consensus about
> >>>> 1.0 content. That’s why I invite everyone to flag issues and PRs with
> >> the
> >>>> 1.0-blocker label.
> >>>> I propose to do a review in 24h. As soon as we don’t have any
> >> 1.0-blocker,
> >>>> we are good to start rc.
> >>>>
> >>>> We can also chat about that during the community meeting today.
> >>>>
> >>>> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on
> >> the
> >>>> main branch mainly about license/notice etc).
> >>>>
> >>>> Thanks !
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
> >>>>
> >>>>> Agree with Dmitri.
> >>>>>
> >>>>> Having clear discussion subjects is crucial for the community to
> follow
> >>>>> the right threads. I think we should only get to consensus about the
> >>>>> particular thread topic and nothing else.
> >>>>>
> >>>>> Consensus in a community in general, at least in my opinion, is more
> >>>>> than two people having the same opinion.
> >>>>>
> >>>>> We should also be careful about giving everybody enough time, and
> >>>>> consider weekends and potentially public regional holidays.
> >>>>>
> >>>>> Regarding the technical actions: The branch name doesn't comply with
> >> the
> >>>>> existing naming convention (the branch naming pattern that JB used),
> >>>>> which is also required to later support semi-automatic releases
> >>>>> (discussed a couple months ago during a community sync call).
> >>>>>
> >>>>> Considering that we do not seem to have a consensus on the content of
> >>>>> the 1.0 release, there are still 1.0-blockers and the wrong branch
> >> name,
> >>>>> I strongly prefer do delete that branch.
> >>>>>
> >>>>> Regarding the release manager, I'm in favor of letting JB drive the
> >>>>> release process to ensure that things go smooth.
> >>>>>
> >>>>> Related note: We already have quite a bunch of branches in the GH
> repo
> >>>>> whose meaning is not clear to me.
> >>>>>
> >>>>> Robert
> >>>>>
> >>>>>
> >>>>> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> >>>>>> Also the
> >>>>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
> >>>>> passed
> >>>>>> the lazy consensus window. But I agreed it's nice to conclude a
> >> thread.
> >>>>>>
> >>>>>> The consensus in that thread was to skip the 0.10.0 release.
> >>>>>>
> >>>>>> From my POV an agreement to skip 0.10.0 does not mean that the
> scope
> >>>> for
> >>>>>> 1.0 is set and agreed upon.
> >>>>>>
> >>>>>> What I'm asking for is proactively engaging with the community
> before
> >>>>>> executing technical actions for a new release as opposed to
> informing
> >>>>> after
> >>>>>> actions are taken.
> >>>>>>
> >>>>>> [1]
> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Dmitri.
> >>>>>>
> >>>>>> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
> >> wrote:
> >>>>>>> The branch name is "1.0.x".
> >>>>>>>
> >>>>>>> Where is this agreement recorded?
> >>>>>>>
> >>>>>>> Discussed multiple times with JB last Thursday(6/5/2025) and this
> >>>>>>> Monday(6/9/2025), we agreed to consider it as a nice-to-have
> instead
> >>>> of
> >>>>> a
> >>>>>>> blocker.
> >>>>>>>
> >>>>>>> As a matter of best practice, given the previous related discussion
> >>>>> thread
> >>>>>>>> [1], it would have been nice to conclude it with a message about
> >>>>> starting
> >>>>>>>> the 1.0 release process before actually cutting the branch.
> >>>>>>> We got consensus on thread[1]. The 1.0 release was also prepared
> way
> >>>>> before
> >>>>>>> the thread. We will kick off 1.0 release even if 0.10 is not
> >> canceled.
> >>>>> JB
> >>>>>>> and I discussed the parallel releasing option for both versions.
> Also
> >>>>> the
> >>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago,
> which
> >>>>> passed
> >>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
> >>>> thread.
> >>>>>>> [1]
> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >>>>>>>
> >>>>>>> Yufei
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
> >> dimas@apache.org
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> I cut the 1.0.x branch yesterday morning.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> As a matter of best practice, given the previous related
> discussion
> >>>>>>> thread
> >>>>>>>> [1], it would have been nice to conclude it with a message about
> >>>>> starting
> >>>>>>>> the 1.0 release process before actually cutting the branch.
> >>>>>>>>
> >>>>>>>> [1]
> >> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >>>>>>>> Thanks,
> >>>>>>>> Dmitri.
> >>>>>>>>
> >>>>>>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
> >>>> wrote:
> >>>>>>>>> Thanks everyone for the contribution. We've finally resolved all
> >>>>>>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
> >>>>> cherry
> >>>>>>>>> pick bug fixes and license related commits to this branch
> starting
> >>>>> now.
> >>>>>>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's
> a
> >>>>>>>>> best-to-have instead of a blocker per offline discussion,
> >>>>>>>>> https://github.com/apache/polaris/pull/1695.
> >>>>>>>>>
> >>>>>>>>> Yufei
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
> >>>> eric.w.maynard@gmail.com
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> +1 to making 801 a blocker.
> >>>>>>>>>>
> >>>>>>>>>> Based on Alex's comments in 1799, it looks like the rotation is
> >>>> only
> >>>>>>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we
> have a
> >>>>>>> very
> >>>>>>>>>> simple fix in PR#1804 <
> >> https://github.com/apache/polaris/pull/1804
> >>>>> .
> >>>>>>>>>> --EM
> >>>>>>>>>>
> >>>>> --
> >>>>> Robert Stupp
> >>>>> @snazy
> >>>>>
> >>>>>
> >> --
> >> Robert Stupp
> >> @snazy
> >>
> >>
> --
> Robert Stupp
> @snazy
>
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Robert Stupp <sn...@snazy.de>.
Heads up: It's also documented in the release-guide via
https://github.com/apache/polaris/pull/1539, not sure you saw it. That
doc also mentions how to apply versions, create tags etc.
On 12.06.25 19:41, Yufei Gu wrote:
> Thanks for the explanation. Created a new branch named "release/1.0.x" for
> the 1.0 release. I will delete "1.0.x" a bit later.
>
>
> Yufei
>
>
> On Thu, Jun 12, 2025 at 9:05 AM Robert Stupp <sn...@snazy.de> wrote:
>
>> Not sure whether everybody followed how the releases were crafted. We
>> discussed the branch naming pattern before during community sync calls.
>> There's also the draft PR 485 for semi-automatic releases that relies on
>> the same naming pattern. To change that, we have to have a discussion on
>> dev@ first.
>>
>> 1695 is for me a legit 1.0-blocker, as it changes the artifact names
>> that users may refer to - including downloadable binary distributions.
>> Either we change it before 1.0 or not at all.
>>
>> PR 485: https://github.com/apache/polaris/pull/485
>>
>>
>> On 12.06.25 17:48, Yufei Gu wrote:
>>> We didn't do that for 0.9 and 0.10 releases before cutting a branch. If
>> you
>>> think that's a new process we need to follow, please open a new dev ML
>>> thread for discussion.
>>>
>>> the wrong branch name
>>>
>>>
>>> Can you explain why there is a wrong branch name?
>>>
>>> Where is this agreement recorded?
>>>
>>> Where is the agreement record of adding [1] as a 1.0 blocker? Can you
>> open
>>> a thread for that if there is not? It seems controversial now.
>>>
>>> [1] https://github.com/apache/polaris/pull/1695.
>>>
>>> Yufei
>>>
>>>
>>> On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> Hi folks
>>>>
>>>> Back from the other part of the pond :)
>>>>
>>>> I think we should have a clear consensus about
>>>> 1.0 content. That’s why I invite everyone to flag issues and PRs with
>> the
>>>> 1.0-blocker label.
>>>> I propose to do a review in 24h. As soon as we don’t have any
>> 1.0-blocker,
>>>> we are good to start rc.
>>>>
>>>> We can also chat about that during the community meeting today.
>>>>
>>>> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on
>> the
>>>> main branch mainly about license/notice etc).
>>>>
>>>> Thanks !
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
>>>>
>>>>> Agree with Dmitri.
>>>>>
>>>>> Having clear discussion subjects is crucial for the community to follow
>>>>> the right threads. I think we should only get to consensus about the
>>>>> particular thread topic and nothing else.
>>>>>
>>>>> Consensus in a community in general, at least in my opinion, is more
>>>>> than two people having the same opinion.
>>>>>
>>>>> We should also be careful about giving everybody enough time, and
>>>>> consider weekends and potentially public regional holidays.
>>>>>
>>>>> Regarding the technical actions: The branch name doesn't comply with
>> the
>>>>> existing naming convention (the branch naming pattern that JB used),
>>>>> which is also required to later support semi-automatic releases
>>>>> (discussed a couple months ago during a community sync call).
>>>>>
>>>>> Considering that we do not seem to have a consensus on the content of
>>>>> the 1.0 release, there are still 1.0-blockers and the wrong branch
>> name,
>>>>> I strongly prefer do delete that branch.
>>>>>
>>>>> Regarding the release manager, I'm in favor of letting JB drive the
>>>>> release process to ensure that things go smooth.
>>>>>
>>>>> Related note: We already have quite a bunch of branches in the GH repo
>>>>> whose meaning is not clear to me.
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
>>>>>> Also the
>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
>>>>> passed
>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>> thread.
>>>>>>
>>>>>> The consensus in that thread was to skip the 0.10.0 release.
>>>>>>
>>>>>> From my POV an agreement to skip 0.10.0 does not mean that the scope
>>>> for
>>>>>> 1.0 is set and agreed upon.
>>>>>>
>>>>>> What I'm asking for is proactively engaging with the community before
>>>>>> executing technical actions for a new release as opposed to informing
>>>>> after
>>>>>> actions are taken.
>>>>>>
>>>>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitri.
>>>>>>
>>>>>> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
>> wrote:
>>>>>>> The branch name is "1.0.x".
>>>>>>>
>>>>>>> Where is this agreement recorded?
>>>>>>>
>>>>>>> Discussed multiple times with JB last Thursday(6/5/2025) and this
>>>>>>> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
>>>> of
>>>>> a
>>>>>>> blocker.
>>>>>>>
>>>>>>> As a matter of best practice, given the previous related discussion
>>>>> thread
>>>>>>>> [1], it would have been nice to conclude it with a message about
>>>>> starting
>>>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>>> We got consensus on thread[1]. The 1.0 release was also prepared way
>>>>> before
>>>>>>> the thread. We will kick off 1.0 release even if 0.10 is not
>> canceled.
>>>>> JB
>>>>>>> and I discussed the parallel releasing option for both versions. Also
>>>>> the
>>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
>>>>> passed
>>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>>>> thread.
>>>>>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>>
>>>>>>> Yufei
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
>> dimas@apache.org
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I cut the 1.0.x branch yesterday morning.
>>>>>>>>
>>>>>>>>
>>>>>>>> As a matter of best practice, given the previous related discussion
>>>>>>> thread
>>>>>>>> [1], it would have been nice to conclude it with a message about
>>>>> starting
>>>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>>>>
>>>>>>>> [1]
>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>>> Thanks,
>>>>>>>> Dmitri.
>>>>>>>>
>>>>>>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
>>>> wrote:
>>>>>>>>> Thanks everyone for the contribution. We've finally resolved all
>>>>>>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
>>>>> cherry
>>>>>>>>> pick bug fixes and license related commits to this branch starting
>>>>> now.
>>>>>>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
>>>>>>>>> best-to-have instead of a blocker per offline discussion,
>>>>>>>>> https://github.com/apache/polaris/pull/1695.
>>>>>>>>>
>>>>>>>>> Yufei
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
>>>> eric.w.maynard@gmail.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> +1 to making 801 a blocker.
>>>>>>>>>>
>>>>>>>>>> Based on Alex's comments in 1799, it looks like the rotation is
>>>> only
>>>>>>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
>>>>>>> very
>>>>>>>>>> simple fix in PR#1804 <
>> https://github.com/apache/polaris/pull/1804
>>>>> .
>>>>>>>>>> --EM
>>>>>>>>>>
>>>>> --
>>>>> Robert Stupp
>>>>> @snazy
>>>>>
>>>>>
>> --
>> Robert Stupp
>> @snazy
>>
>>
--
Robert Stupp
@snazy
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Yufei Gu <fl...@gmail.com>.
Thanks for the explanation. Created a new branch named "release/1.0.x" for
the 1.0 release. I will delete "1.0.x" a bit later.
Yufei
On Thu, Jun 12, 2025 at 9:05 AM Robert Stupp <sn...@snazy.de> wrote:
> Not sure whether everybody followed how the releases were crafted. We
> discussed the branch naming pattern before during community sync calls.
> There's also the draft PR 485 for semi-automatic releases that relies on
> the same naming pattern. To change that, we have to have a discussion on
> dev@ first.
>
> 1695 is for me a legit 1.0-blocker, as it changes the artifact names
> that users may refer to - including downloadable binary distributions.
> Either we change it before 1.0 or not at all.
>
> PR 485: https://github.com/apache/polaris/pull/485
>
>
> On 12.06.25 17:48, Yufei Gu wrote:
> > We didn't do that for 0.9 and 0.10 releases before cutting a branch. If
> you
> > think that's a new process we need to follow, please open a new dev ML
> > thread for discussion.
> >
> > the wrong branch name
> >
> >
> > Can you explain why there is a wrong branch name?
> >
> > Where is this agreement recorded?
> >
> > Where is the agreement record of adding [1] as a 1.0 blocker? Can you
> open
> > a thread for that if there is not? It seems controversial now.
> >
> > [1] https://github.com/apache/polaris/pull/1695.
> >
> > Yufei
> >
> >
> > On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> >> Hi folks
> >>
> >> Back from the other part of the pond :)
> >>
> >> I think we should have a clear consensus about
> >> 1.0 content. That’s why I invite everyone to flag issues and PRs with
> the
> >> 1.0-blocker label.
> >> I propose to do a review in 24h. As soon as we don’t have any
> 1.0-blocker,
> >> we are good to start rc.
> >>
> >> We can also chat about that during the community meeting today.
> >>
> >> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on
> the
> >> main branch mainly about license/notice etc).
> >>
> >> Thanks !
> >>
> >> Regards
> >> JB
> >>
> >> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
> >>
> >>> Agree with Dmitri.
> >>>
> >>> Having clear discussion subjects is crucial for the community to follow
> >>> the right threads. I think we should only get to consensus about the
> >>> particular thread topic and nothing else.
> >>>
> >>> Consensus in a community in general, at least in my opinion, is more
> >>> than two people having the same opinion.
> >>>
> >>> We should also be careful about giving everybody enough time, and
> >>> consider weekends and potentially public regional holidays.
> >>>
> >>> Regarding the technical actions: The branch name doesn't comply with
> the
> >>> existing naming convention (the branch naming pattern that JB used),
> >>> which is also required to later support semi-automatic releases
> >>> (discussed a couple months ago during a community sync call).
> >>>
> >>> Considering that we do not seem to have a consensus on the content of
> >>> the 1.0 release, there are still 1.0-blockers and the wrong branch
> name,
> >>> I strongly prefer do delete that branch.
> >>>
> >>> Regarding the release manager, I'm in favor of letting JB drive the
> >>> release process to ensure that things go smooth.
> >>>
> >>> Related note: We already have quite a bunch of branches in the GH repo
> >>> whose meaning is not clear to me.
> >>>
> >>> Robert
> >>>
> >>>
> >>> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> >>>> Also the
> >>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
> >>> passed
> >>>> the lazy consensus window. But I agreed it's nice to conclude a
> thread.
> >>>>
> >>>>
> >>>> The consensus in that thread was to skip the 0.10.0 release.
> >>>>
> >>>> From my POV an agreement to skip 0.10.0 does not mean that the scope
> >> for
> >>>> 1.0 is set and agreed upon.
> >>>>
> >>>> What I'm asking for is proactively engaging with the community before
> >>>> executing technical actions for a new release as opposed to informing
> >>> after
> >>>> actions are taken.
> >>>>
> >>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >>>>
> >>>> Thanks,
> >>>> Dmitri.
> >>>>
> >>>> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
> wrote:
> >>>>
> >>>>> The branch name is "1.0.x".
> >>>>>
> >>>>> Where is this agreement recorded?
> >>>>>
> >>>>> Discussed multiple times with JB last Thursday(6/5/2025) and this
> >>>>> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
> >> of
> >>> a
> >>>>> blocker.
> >>>>>
> >>>>> As a matter of best practice, given the previous related discussion
> >>> thread
> >>>>>> [1], it would have been nice to conclude it with a message about
> >>> starting
> >>>>>> the 1.0 release process before actually cutting the branch.
> >>>>> We got consensus on thread[1]. The 1.0 release was also prepared way
> >>> before
> >>>>> the thread. We will kick off 1.0 release even if 0.10 is not
> canceled.
> >>> JB
> >>>>> and I discussed the parallel releasing option for both versions. Also
> >>> the
> >>>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
> >>> passed
> >>>>> the lazy consensus window. But I agreed it's nice to conclude a
> >> thread.
> >>>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >>>>>
> >>>>> Yufei
> >>>>>
> >>>>>
> >>>>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
> dimas@apache.org
> >>>>> wrote:
> >>>>>
> >>>>>> I cut the 1.0.x branch yesterday morning.
> >>>>>>
> >>>>>>
> >>>>>> As a matter of best practice, given the previous related discussion
> >>>>> thread
> >>>>>> [1], it would have been nice to conclude it with a message about
> >>> starting
> >>>>>> the 1.0 release process before actually cutting the branch.
> >>>>>>
> >>>>>> [1]
> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Dmitri.
> >>>>>>
> >>>>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
> >> wrote:
> >>>>>>> Thanks everyone for the contribution. We've finally resolved all
> >>>>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
> >>> cherry
> >>>>>>> pick bug fixes and license related commits to this branch starting
> >>> now.
> >>>>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> >>>>>>> best-to-have instead of a blocker per offline discussion,
> >>>>>>> https://github.com/apache/polaris/pull/1695.
> >>>>>>>
> >>>>>>> Yufei
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
> >> eric.w.maynard@gmail.com
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> +1 to making 801 a blocker.
> >>>>>>>>
> >>>>>>>> Based on Alex's comments in 1799, it looks like the rotation is
> >> only
> >>>>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
> >>>>> very
> >>>>>>>> simple fix in PR#1804 <
> https://github.com/apache/polaris/pull/1804
> >>> .
> >>>>>>>> --EM
> >>>>>>>>
> >>> --
> >>> Robert Stupp
> >>> @snazy
> >>>
> >>>
> --
> Robert Stupp
> @snazy
>
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Robert Stupp <sn...@snazy.de>.
Not sure whether everybody followed how the releases were crafted. We
discussed the branch naming pattern before during community sync calls.
There's also the draft PR 485 for semi-automatic releases that relies on
the same naming pattern. To change that, we have to have a discussion on
dev@ first.
1695 is for me a legit 1.0-blocker, as it changes the artifact names
that users may refer to - including downloadable binary distributions.
Either we change it before 1.0 or not at all.
PR 485: https://github.com/apache/polaris/pull/485
On 12.06.25 17:48, Yufei Gu wrote:
> We didn't do that for 0.9 and 0.10 releases before cutting a branch. If you
> think that's a new process we need to follow, please open a new dev ML
> thread for discussion.
>
> the wrong branch name
>
>
> Can you explain why there is a wrong branch name?
>
> Where is this agreement recorded?
>
> Where is the agreement record of adding [1] as a 1.0 blocker? Can you open
> a thread for that if there is not? It seems controversial now.
>
> [1] https://github.com/apache/polaris/pull/1695.
>
> Yufei
>
>
> On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi folks
>>
>> Back from the other part of the pond :)
>>
>> I think we should have a clear consensus about
>> 1.0 content. That’s why I invite everyone to flag issues and PRs with the
>> 1.0-blocker label.
>> I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
>> we are good to start rc.
>>
>> We can also chat about that during the community meeting today.
>>
>> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
>> main branch mainly about license/notice etc).
>>
>> Thanks !
>>
>> Regards
>> JB
>>
>> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
>>
>>> Agree with Dmitri.
>>>
>>> Having clear discussion subjects is crucial for the community to follow
>>> the right threads. I think we should only get to consensus about the
>>> particular thread topic and nothing else.
>>>
>>> Consensus in a community in general, at least in my opinion, is more
>>> than two people having the same opinion.
>>>
>>> We should also be careful about giving everybody enough time, and
>>> consider weekends and potentially public regional holidays.
>>>
>>> Regarding the technical actions: The branch name doesn't comply with the
>>> existing naming convention (the branch naming pattern that JB used),
>>> which is also required to later support semi-automatic releases
>>> (discussed a couple months ago during a community sync call).
>>>
>>> Considering that we do not seem to have a consensus on the content of
>>> the 1.0 release, there are still 1.0-blockers and the wrong branch name,
>>> I strongly prefer do delete that branch.
>>>
>>> Regarding the release manager, I'm in favor of letting JB drive the
>>> release process to ensure that things go smooth.
>>>
>>> Related note: We already have quite a bunch of branches in the GH repo
>>> whose meaning is not clear to me.
>>>
>>> Robert
>>>
>>>
>>> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
>>>> Also the
>>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
>>> passed
>>>> the lazy consensus window. But I agreed it's nice to conclude a thread.
>>>>
>>>>
>>>> The consensus in that thread was to skip the 0.10.0 release.
>>>>
>>>> From my POV an agreement to skip 0.10.0 does not mean that the scope
>> for
>>>> 1.0 is set and agreed upon.
>>>>
>>>> What I'm asking for is proactively engaging with the community before
>>>> executing technical actions for a new release as opposed to informing
>>> after
>>>> actions are taken.
>>>>
>>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>
>>>> Thanks,
>>>> Dmitri.
>>>>
>>>> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com> wrote:
>>>>
>>>>> The branch name is "1.0.x".
>>>>>
>>>>> Where is this agreement recorded?
>>>>>
>>>>> Discussed multiple times with JB last Thursday(6/5/2025) and this
>>>>> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
>> of
>>> a
>>>>> blocker.
>>>>>
>>>>> As a matter of best practice, given the previous related discussion
>>> thread
>>>>>> [1], it would have been nice to conclude it with a message about
>>> starting
>>>>>> the 1.0 release process before actually cutting the branch.
>>>>> We got consensus on thread[1]. The 1.0 release was also prepared way
>>> before
>>>>> the thread. We will kick off 1.0 release even if 0.10 is not canceled.
>>> JB
>>>>> and I discussed the parallel releasing option for both versions. Also
>>> the
>>>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
>>> passed
>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>> thread.
>>>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>
>>>>> Yufei
>>>>>
>>>>>
>>>>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <dimas@apache.org
>>>>> wrote:
>>>>>
>>>>>> I cut the 1.0.x branch yesterday morning.
>>>>>>
>>>>>>
>>>>>> As a matter of best practice, given the previous related discussion
>>>>> thread
>>>>>> [1], it would have been nice to conclude it with a message about
>>> starting
>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>>
>>>>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitri.
>>>>>>
>>>>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
>> wrote:
>>>>>>> Thanks everyone for the contribution. We've finally resolved all
>>>>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
>>> cherry
>>>>>>> pick bug fixes and license related commits to this branch starting
>>> now.
>>>>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
>>>>>>> best-to-have instead of a blocker per offline discussion,
>>>>>>> https://github.com/apache/polaris/pull/1695.
>>>>>>>
>>>>>>> Yufei
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
>> eric.w.maynard@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1 to making 801 a blocker.
>>>>>>>>
>>>>>>>> Based on Alex's comments in 1799, it looks like the rotation is
>> only
>>>>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
>>>>> very
>>>>>>>> simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804
>>> .
>>>>>>>> --EM
>>>>>>>>
>>> --
>>> Robert Stupp
>>> @snazy
>>>
>>>
--
Robert Stupp
@snazy
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Yufei Gu <fl...@gmail.com>.
We didn't do that for 0.9 and 0.10 releases before cutting a branch. If you
think that's a new process we need to follow, please open a new dev ML
thread for discussion.
the wrong branch name
Can you explain why there is a wrong branch name?
Where is this agreement recorded?
Where is the agreement record of adding [1] as a 1.0 blocker? Can you open
a thread for that if there is not? It seems controversial now.
[1] https://github.com/apache/polaris/pull/1695.
Yufei
On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi folks
>
> Back from the other part of the pond :)
>
> I think we should have a clear consensus about
> 1.0 content. That’s why I invite everyone to flag issues and PRs with the
> 1.0-blocker label.
> I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
> we are good to start rc.
>
> We can also chat about that during the community meeting today.
>
> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
> main branch mainly about license/notice etc).
>
> Thanks !
>
> Regards
> JB
>
> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
>
> > Agree with Dmitri.
> >
> > Having clear discussion subjects is crucial for the community to follow
> > the right threads. I think we should only get to consensus about the
> > particular thread topic and nothing else.
> >
> > Consensus in a community in general, at least in my opinion, is more
> > than two people having the same opinion.
> >
> > We should also be careful about giving everybody enough time, and
> > consider weekends and potentially public regional holidays.
> >
> > Regarding the technical actions: The branch name doesn't comply with the
> > existing naming convention (the branch naming pattern that JB used),
> > which is also required to later support semi-automatic releases
> > (discussed a couple months ago during a community sync call).
> >
> > Considering that we do not seem to have a consensus on the content of
> > the 1.0 release, there are still 1.0-blockers and the wrong branch name,
> > I strongly prefer do delete that branch.
> >
> > Regarding the release manager, I'm in favor of letting JB drive the
> > release process to ensure that things go smooth.
> >
> > Related note: We already have quite a bunch of branches in the GH repo
> > whose meaning is not clear to me.
> >
> > Robert
> >
> >
> > On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> > > Also the
> > > last PPMC member's agreement on thread[1] happened 5 days ago, which
> > passed
> > > the lazy consensus window. But I agreed it's nice to conclude a thread.
> > >
> > >
> > > The consensus in that thread was to skip the 0.10.0 release.
> > >
> > > From my POV an agreement to skip 0.10.0 does not mean that the scope
> for
> > > 1.0 is set and agreed upon.
> > >
> > > What I'm asking for is proactively engaging with the community before
> > > executing technical actions for a new release as opposed to informing
> > after
> > > actions are taken.
> > >
> > > [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >
> > > Thanks,
> > > Dmitri.
> > >
> > > On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com> wrote:
> > >
> > >> The branch name is "1.0.x".
> > >>
> > >> Where is this agreement recorded?
> > >>
> > >> Discussed multiple times with JB last Thursday(6/5/2025) and this
> > >> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
> of
> > a
> > >> blocker.
> > >>
> > >> As a matter of best practice, given the previous related discussion
> > thread
> > >>> [1], it would have been nice to conclude it with a message about
> > starting
> > >>> the 1.0 release process before actually cutting the branch.
> > >> We got consensus on thread[1]. The 1.0 release was also prepared way
> > before
> > >> the thread. We will kick off 1.0 release even if 0.10 is not canceled.
> > JB
> > >> and I discussed the parallel releasing option for both versions. Also
> > the
> > >> last PPMC member's agreement on thread[1] happened 5 days ago, which
> > passed
> > >> the lazy consensus window. But I agreed it's nice to conclude a
> thread.
> > >>
> > >> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >>
> > >> Yufei
> > >>
> > >>
> > >> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <dimas@apache.org
> >
> > >> wrote:
> > >>
> > >>> I cut the 1.0.x branch yesterday morning.
> > >>>
> > >>>
> > >>> As a matter of best practice, given the previous related discussion
> > >> thread
> > >>> [1], it would have been nice to conclude it with a message about
> > starting
> > >>> the 1.0 release process before actually cutting the branch.
> > >>>
> > >>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >>>
> > >>> Thanks,
> > >>> Dmitri.
> > >>>
> > >>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
> wrote:
> > >>>
> > >>>> Thanks everyone for the contribution. We've finally resolved all
> > >>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
> > cherry
> > >>>> pick bug fixes and license related commits to this branch starting
> > now.
> > >>>>
> > >>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> > >>>> best-to-have instead of a blocker per offline discussion,
> > >>>> https://github.com/apache/polaris/pull/1695.
> > >>>>
> > >>>> Yufei
> > >>>>
> > >>>>
> > >>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
> eric.w.maynard@gmail.com
> > >
> > >>>> wrote:
> > >>>>
> > >>>>> +1 to making 801 a blocker.
> > >>>>>
> > >>>>> Based on Alex's comments in 1799, it looks like the rotation is
> only
> > >>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
> > >> very
> > >>>>> simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804
> >.
> > >>>>>
> > >>>>> --EM
> > >>>>>
> > --
> > Robert Stupp
> > @snazy
> >
> >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Robert Stupp <sn...@snazy.de>.
+1 on "1.0-blocker" for both 1889 + 1890
On 13.06.25 04:24, Dmitri Bourlatchkov wrote:
> As discussed in the community sync today, I opened PR [1890] to inform
> users about what to expect in terms of backward compatibility as the
> project evolves.
>
> I proactively marked it as 1.0 blocker because I'm not sure whether docs
> have to be merged before the release in order to be reflected in the
> appropriate release section of the Polaris website. If 1.0 docs can be
> adjusted after the release, I suppose this PR does not have to be a blocker.
>
> Comments and suggestions are welcome.
>
> [1890] https://github.com/apache/polaris/pull/1890
>
> Thanks,
> Dmitri.
>
> On Thu, Jun 12, 2025 at 8:15 PM Dmitri Bourlatchkov <di...@apache.org>
> wrote:
>
>> I've marked [1889] as a 1.0 blocker. Feel free to disagree :) My rationale:
>>
>> Polaris 1.0 is a binary release and will provide a platform for users to
>> experiment with Generic Tables. It is important to set correct expectations
>> about this feature in terms of functional scope, level of maturity, plans
>> for evolution.... which is what the PR hopefully provides (I did not review
>> yet :) )
>>
>> [1889] https://github.com/apache/polaris/pull/1889
>>
>> Cheers,
>> Dmitri.
>>
>> On Thu, Jun 12, 2025 at 7:17 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Hi folks
>>>
>>> Back from the other part of the pond :)
>>>
>>> I think we should have a clear consensus about
>>> 1.0 content. That’s why I invite everyone to flag issues and PRs with the
>>> 1.0-blocker label.
>>> I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
>>> we are good to start rc.
>>>
>>> We can also chat about that during the community meeting today.
>>>
>>> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
>>> main branch mainly about license/notice etc).
>>>
>>> Thanks !
>>>
>>> Regards
>>> JB
>>>
>>> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
>>>
>>>> Agree with Dmitri.
>>>>
>>>> Having clear discussion subjects is crucial for the community to follow
>>>> the right threads. I think we should only get to consensus about the
>>>> particular thread topic and nothing else.
>>>>
>>>> Consensus in a community in general, at least in my opinion, is more
>>>> than two people having the same opinion.
>>>>
>>>> We should also be careful about giving everybody enough time, and
>>>> consider weekends and potentially public regional holidays.
>>>>
>>>> Regarding the technical actions: The branch name doesn't comply with the
>>>> existing naming convention (the branch naming pattern that JB used),
>>>> which is also required to later support semi-automatic releases
>>>> (discussed a couple months ago during a community sync call).
>>>>
>>>> Considering that we do not seem to have a consensus on the content of
>>>> the 1.0 release, there are still 1.0-blockers and the wrong branch name,
>>>> I strongly prefer do delete that branch.
>>>>
>>>> Regarding the release manager, I'm in favor of letting JB drive the
>>>> release process to ensure that things go smooth.
>>>>
>>>> Related note: We already have quite a bunch of branches in the GH repo
>>>> whose meaning is not clear to me.
>>>>
>>>> Robert
>>>>
>>>>
>>>> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
>>>>> Also the
>>>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
>>>> passed
>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>>> thread.
>>>>>
>>>>> The consensus in that thread was to skip the 0.10.0 release.
>>>>>
>>>>> From my POV an agreement to skip 0.10.0 does not mean that the scope
>>> for
>>>>> 1.0 is set and agreed upon.
>>>>>
>>>>> What I'm asking for is proactively engaging with the community before
>>>>> executing technical actions for a new release as opposed to informing
>>>> after
>>>>> actions are taken.
>>>>>
>>>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>
>>>>> Thanks,
>>>>> Dmitri.
>>>>>
>>>>> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
>>> wrote:
>>>>>> The branch name is "1.0.x".
>>>>>>
>>>>>> Where is this agreement recorded?
>>>>>>
>>>>>> Discussed multiple times with JB last Thursday(6/5/2025) and this
>>>>>> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
>>> of
>>>> a
>>>>>> blocker.
>>>>>>
>>>>>> As a matter of best practice, given the previous related discussion
>>>> thread
>>>>>>> [1], it would have been nice to conclude it with a message about
>>>> starting
>>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>> We got consensus on thread[1]. The 1.0 release was also prepared way
>>>> before
>>>>>> the thread. We will kick off 1.0 release even if 0.10 is not
>>> canceled.
>>>> JB
>>>>>> and I discussed the parallel releasing option for both versions. Also
>>>> the
>>>>>> last PPMC member's agreement on thread[1] happened 5 days ago, which
>>>> passed
>>>>>> the lazy consensus window. But I agreed it's nice to conclude a
>>> thread.
>>>>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>
>>>>>> Yufei
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
>>> dimas@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> I cut the 1.0.x branch yesterday morning.
>>>>>>>
>>>>>>>
>>>>>>> As a matter of best practice, given the previous related discussion
>>>>>> thread
>>>>>>> [1], it would have been nice to conclude it with a message about
>>>> starting
>>>>>>> the 1.0 release process before actually cutting the branch.
>>>>>>>
>>>>>>> [1]
>>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>>>>> Thanks,
>>>>>>> Dmitri.
>>>>>>>
>>>>>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
>>> wrote:
>>>>>>>> Thanks everyone for the contribution. We've finally resolved all
>>>>>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
>>>> cherry
>>>>>>>> pick bug fixes and license related commits to this branch starting
>>>> now.
>>>>>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
>>>>>>>> best-to-have instead of a blocker per offline discussion,
>>>>>>>> https://github.com/apache/polaris/pull/1695.
>>>>>>>>
>>>>>>>> Yufei
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
>>> eric.w.maynard@gmail.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> +1 to making 801 a blocker.
>>>>>>>>>
>>>>>>>>> Based on Alex's comments in 1799, it looks like the rotation is
>>> only
>>>>>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
>>>>>> very
>>>>>>>>> simple fix in PR#1804 <
>>> https://github.com/apache/polaris/pull/1804>.
>>>>>>>>> --EM
>>>>>>>>>
>>>> --
>>>> Robert Stupp
>>>> @snazy
>>>>
>>>>
--
Robert Stupp
@snazy
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <di...@apache.org>.
As discussed in the community sync today, I opened PR [1890] to inform
users about what to expect in terms of backward compatibility as the
project evolves.
I proactively marked it as 1.0 blocker because I'm not sure whether docs
have to be merged before the release in order to be reflected in the
appropriate release section of the Polaris website. If 1.0 docs can be
adjusted after the release, I suppose this PR does not have to be a blocker.
Comments and suggestions are welcome.
[1890] https://github.com/apache/polaris/pull/1890
Thanks,
Dmitri.
On Thu, Jun 12, 2025 at 8:15 PM Dmitri Bourlatchkov <di...@apache.org>
wrote:
> I've marked [1889] as a 1.0 blocker. Feel free to disagree :) My rationale:
>
> Polaris 1.0 is a binary release and will provide a platform for users to
> experiment with Generic Tables. It is important to set correct expectations
> about this feature in terms of functional scope, level of maturity, plans
> for evolution.... which is what the PR hopefully provides (I did not review
> yet :) )
>
> [1889] https://github.com/apache/polaris/pull/1889
>
> Cheers,
> Dmitri.
>
> On Thu, Jun 12, 2025 at 7:17 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi folks
>>
>> Back from the other part of the pond :)
>>
>> I think we should have a clear consensus about
>> 1.0 content. That’s why I invite everyone to flag issues and PRs with the
>> 1.0-blocker label.
>> I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
>> we are good to start rc.
>>
>> We can also chat about that during the community meeting today.
>>
>> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
>> main branch mainly about license/notice etc).
>>
>> Thanks !
>>
>> Regards
>> JB
>>
>> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
>>
>> > Agree with Dmitri.
>> >
>> > Having clear discussion subjects is crucial for the community to follow
>> > the right threads. I think we should only get to consensus about the
>> > particular thread topic and nothing else.
>> >
>> > Consensus in a community in general, at least in my opinion, is more
>> > than two people having the same opinion.
>> >
>> > We should also be careful about giving everybody enough time, and
>> > consider weekends and potentially public regional holidays.
>> >
>> > Regarding the technical actions: The branch name doesn't comply with the
>> > existing naming convention (the branch naming pattern that JB used),
>> > which is also required to later support semi-automatic releases
>> > (discussed a couple months ago during a community sync call).
>> >
>> > Considering that we do not seem to have a consensus on the content of
>> > the 1.0 release, there are still 1.0-blockers and the wrong branch name,
>> > I strongly prefer do delete that branch.
>> >
>> > Regarding the release manager, I'm in favor of letting JB drive the
>> > release process to ensure that things go smooth.
>> >
>> > Related note: We already have quite a bunch of branches in the GH repo
>> > whose meaning is not clear to me.
>> >
>> > Robert
>> >
>> >
>> > On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
>> > > Also the
>> > > last PPMC member's agreement on thread[1] happened 5 days ago, which
>> > passed
>> > > the lazy consensus window. But I agreed it's nice to conclude a
>> thread.
>> > >
>> > >
>> > > The consensus in that thread was to skip the 0.10.0 release.
>> > >
>> > > From my POV an agreement to skip 0.10.0 does not mean that the scope
>> for
>> > > 1.0 is set and agreed upon.
>> > >
>> > > What I'm asking for is proactively engaging with the community before
>> > > executing technical actions for a new release as opposed to informing
>> > after
>> > > actions are taken.
>> > >
>> > > [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>> > >
>> > > Thanks,
>> > > Dmitri.
>> > >
>> > > On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com>
>> wrote:
>> > >
>> > >> The branch name is "1.0.x".
>> > >>
>> > >> Where is this agreement recorded?
>> > >>
>> > >> Discussed multiple times with JB last Thursday(6/5/2025) and this
>> > >> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
>> of
>> > a
>> > >> blocker.
>> > >>
>> > >> As a matter of best practice, given the previous related discussion
>> > thread
>> > >>> [1], it would have been nice to conclude it with a message about
>> > starting
>> > >>> the 1.0 release process before actually cutting the branch.
>> > >> We got consensus on thread[1]. The 1.0 release was also prepared way
>> > before
>> > >> the thread. We will kick off 1.0 release even if 0.10 is not
>> canceled.
>> > JB
>> > >> and I discussed the parallel releasing option for both versions. Also
>> > the
>> > >> last PPMC member's agreement on thread[1] happened 5 days ago, which
>> > passed
>> > >> the lazy consensus window. But I agreed it's nice to conclude a
>> thread.
>> > >>
>> > >> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>> > >>
>> > >> Yufei
>> > >>
>> > >>
>> > >> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
>> dimas@apache.org>
>> > >> wrote:
>> > >>
>> > >>> I cut the 1.0.x branch yesterday morning.
>> > >>>
>> > >>>
>> > >>> As a matter of best practice, given the previous related discussion
>> > >> thread
>> > >>> [1], it would have been nice to conclude it with a message about
>> > starting
>> > >>> the 1.0 release process before actually cutting the branch.
>> > >>>
>> > >>> [1]
>> https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>> > >>>
>> > >>> Thanks,
>> > >>> Dmitri.
>> > >>>
>> > >>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
>> wrote:
>> > >>>
>> > >>>> Thanks everyone for the contribution. We've finally resolved all
>> > >>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
>> > cherry
>> > >>>> pick bug fixes and license related commits to this branch starting
>> > now.
>> > >>>>
>> > >>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
>> > >>>> best-to-have instead of a blocker per offline discussion,
>> > >>>> https://github.com/apache/polaris/pull/1695.
>> > >>>>
>> > >>>> Yufei
>> > >>>>
>> > >>>>
>> > >>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
>> eric.w.maynard@gmail.com
>> > >
>> > >>>> wrote:
>> > >>>>
>> > >>>>> +1 to making 801 a blocker.
>> > >>>>>
>> > >>>>> Based on Alex's comments in 1799, it looks like the rotation is
>> only
>> > >>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
>> > >> very
>> > >>>>> simple fix in PR#1804 <
>> https://github.com/apache/polaris/pull/1804>.
>> > >>>>>
>> > >>>>> --EM
>> > >>>>>
>> > --
>> > Robert Stupp
>> > @snazy
>> >
>> >
>>
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <di...@apache.org>.
I've marked [1889] as a 1.0 blocker. Feel free to disagree :) My rationale:
Polaris 1.0 is a binary release and will provide a platform for users to
experiment with Generic Tables. It is important to set correct expectations
about this feature in terms of functional scope, level of maturity, plans
for evolution.... which is what the PR hopefully provides (I did not review
yet :) )
[1889] https://github.com/apache/polaris/pull/1889
Cheers,
Dmitri.
On Thu, Jun 12, 2025 at 7:17 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi folks
>
> Back from the other part of the pond :)
>
> I think we should have a clear consensus about
> 1.0 content. That’s why I invite everyone to flag issues and PRs with the
> 1.0-blocker label.
> I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
> we are good to start rc.
>
> We can also chat about that during the community meeting today.
>
> If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
> main branch mainly about license/notice etc).
>
> Thanks !
>
> Regards
> JB
>
> Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
>
> > Agree with Dmitri.
> >
> > Having clear discussion subjects is crucial for the community to follow
> > the right threads. I think we should only get to consensus about the
> > particular thread topic and nothing else.
> >
> > Consensus in a community in general, at least in my opinion, is more
> > than two people having the same opinion.
> >
> > We should also be careful about giving everybody enough time, and
> > consider weekends and potentially public regional holidays.
> >
> > Regarding the technical actions: The branch name doesn't comply with the
> > existing naming convention (the branch naming pattern that JB used),
> > which is also required to later support semi-automatic releases
> > (discussed a couple months ago during a community sync call).
> >
> > Considering that we do not seem to have a consensus on the content of
> > the 1.0 release, there are still 1.0-blockers and the wrong branch name,
> > I strongly prefer do delete that branch.
> >
> > Regarding the release manager, I'm in favor of letting JB drive the
> > release process to ensure that things go smooth.
> >
> > Related note: We already have quite a bunch of branches in the GH repo
> > whose meaning is not clear to me.
> >
> > Robert
> >
> >
> > On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> > > Also the
> > > last PPMC member's agreement on thread[1] happened 5 days ago, which
> > passed
> > > the lazy consensus window. But I agreed it's nice to conclude a thread.
> > >
> > >
> > > The consensus in that thread was to skip the 0.10.0 release.
> > >
> > > From my POV an agreement to skip 0.10.0 does not mean that the scope
> for
> > > 1.0 is set and agreed upon.
> > >
> > > What I'm asking for is proactively engaging with the community before
> > > executing technical actions for a new release as opposed to informing
> > after
> > > actions are taken.
> > >
> > > [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >
> > > Thanks,
> > > Dmitri.
> > >
> > > On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com> wrote:
> > >
> > >> The branch name is "1.0.x".
> > >>
> > >> Where is this agreement recorded?
> > >>
> > >> Discussed multiple times with JB last Thursday(6/5/2025) and this
> > >> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
> of
> > a
> > >> blocker.
> > >>
> > >> As a matter of best practice, given the previous related discussion
> > thread
> > >>> [1], it would have been nice to conclude it with a message about
> > starting
> > >>> the 1.0 release process before actually cutting the branch.
> > >> We got consensus on thread[1]. The 1.0 release was also prepared way
> > before
> > >> the thread. We will kick off 1.0 release even if 0.10 is not canceled.
> > JB
> > >> and I discussed the parallel releasing option for both versions. Also
> > the
> > >> last PPMC member's agreement on thread[1] happened 5 days ago, which
> > passed
> > >> the lazy consensus window. But I agreed it's nice to conclude a
> thread.
> > >>
> > >> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >>
> > >> Yufei
> > >>
> > >>
> > >> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <dimas@apache.org
> >
> > >> wrote:
> > >>
> > >>> I cut the 1.0.x branch yesterday morning.
> > >>>
> > >>>
> > >>> As a matter of best practice, given the previous related discussion
> > >> thread
> > >>> [1], it would have been nice to conclude it with a message about
> > starting
> > >>> the 1.0 release process before actually cutting the branch.
> > >>>
> > >>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> > >>>
> > >>> Thanks,
> > >>> Dmitri.
> > >>>
> > >>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com>
> wrote:
> > >>>
> > >>>> Thanks everyone for the contribution. We've finally resolved all
> > >>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
> > cherry
> > >>>> pick bug fixes and license related commits to this branch starting
> > now.
> > >>>>
> > >>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> > >>>> best-to-have instead of a blocker per offline discussion,
> > >>>> https://github.com/apache/polaris/pull/1695.
> > >>>>
> > >>>> Yufei
> > >>>>
> > >>>>
> > >>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
> eric.w.maynard@gmail.com
> > >
> > >>>> wrote:
> > >>>>
> > >>>>> +1 to making 801 a blocker.
> > >>>>>
> > >>>>> Based on Alex's comments in 1799, it looks like the rotation is
> only
> > >>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
> > >> very
> > >>>>> simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804
> >.
> > >>>>>
> > >>>>> --EM
> > >>>>>
> > --
> > Robert Stupp
> > @snazy
> >
> >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi folks
Back from the other part of the pond :)
I think we should have a clear consensus about
1.0 content. That’s why I invite everyone to flag issues and PRs with the
1.0-blocker label.
I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
we are good to start rc.
We can also chat about that during the community meeting today.
If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
main branch mainly about license/notice etc).
Thanks !
Regards
JB
Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
> Agree with Dmitri.
>
> Having clear discussion subjects is crucial for the community to follow
> the right threads. I think we should only get to consensus about the
> particular thread topic and nothing else.
>
> Consensus in a community in general, at least in my opinion, is more
> than two people having the same opinion.
>
> We should also be careful about giving everybody enough time, and
> consider weekends and potentially public regional holidays.
>
> Regarding the technical actions: The branch name doesn't comply with the
> existing naming convention (the branch naming pattern that JB used),
> which is also required to later support semi-automatic releases
> (discussed a couple months ago during a community sync call).
>
> Considering that we do not seem to have a consensus on the content of
> the 1.0 release, there are still 1.0-blockers and the wrong branch name,
> I strongly prefer do delete that branch.
>
> Regarding the release manager, I'm in favor of letting JB drive the
> release process to ensure that things go smooth.
>
> Related note: We already have quite a bunch of branches in the GH repo
> whose meaning is not clear to me.
>
> Robert
>
>
> On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> > Also the
> > last PPMC member's agreement on thread[1] happened 5 days ago, which
> passed
> > the lazy consensus window. But I agreed it's nice to conclude a thread.
> >
> >
> > The consensus in that thread was to skip the 0.10.0 release.
> >
> > From my POV an agreement to skip 0.10.0 does not mean that the scope for
> > 1.0 is set and agreed upon.
> >
> > What I'm asking for is proactively engaging with the community before
> > executing technical actions for a new release as opposed to informing
> after
> > actions are taken.
> >
> > [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >
> > Thanks,
> > Dmitri.
> >
> > On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com> wrote:
> >
> >> The branch name is "1.0.x".
> >>
> >> Where is this agreement recorded?
> >>
> >> Discussed multiple times with JB last Thursday(6/5/2025) and this
> >> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead of
> a
> >> blocker.
> >>
> >> As a matter of best practice, given the previous related discussion
> thread
> >>> [1], it would have been nice to conclude it with a message about
> starting
> >>> the 1.0 release process before actually cutting the branch.
> >> We got consensus on thread[1]. The 1.0 release was also prepared way
> before
> >> the thread. We will kick off 1.0 release even if 0.10 is not canceled.
> JB
> >> and I discussed the parallel releasing option for both versions. Also
> the
> >> last PPMC member's agreement on thread[1] happened 5 days ago, which
> passed
> >> the lazy consensus window. But I agreed it's nice to conclude a thread.
> >>
> >> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >>
> >> Yufei
> >>
> >>
> >> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <di...@apache.org>
> >> wrote:
> >>
> >>> I cut the 1.0.x branch yesterday morning.
> >>>
> >>>
> >>> As a matter of best practice, given the previous related discussion
> >> thread
> >>> [1], it would have been nice to conclude it with a message about
> starting
> >>> the 1.0 release process before actually cutting the branch.
> >>>
> >>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >>>
> >>> Thanks,
> >>> Dmitri.
> >>>
> >>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com> wrote:
> >>>
> >>>> Thanks everyone for the contribution. We've finally resolved all
> >>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
> cherry
> >>>> pick bug fixes and license related commits to this branch starting
> now.
> >>>>
> >>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> >>>> best-to-have instead of a blocker per offline discussion,
> >>>> https://github.com/apache/polaris/pull/1695.
> >>>>
> >>>> Yufei
> >>>>
> >>>>
> >>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <eric.w.maynard@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>> +1 to making 801 a blocker.
> >>>>>
> >>>>> Based on Alex's comments in 1799, it looks like the rotation is only
> >>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
> >> very
> >>>>> simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
> >>>>>
> >>>>> --EM
> >>>>>
> --
> Robert Stupp
> @snazy
>
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Robert Stupp <sn...@snazy.de>.
Agree with Dmitri.
Having clear discussion subjects is crucial for the community to follow
the right threads. I think we should only get to consensus about the
particular thread topic and nothing else.
Consensus in a community in general, at least in my opinion, is more
than two people having the same opinion.
We should also be careful about giving everybody enough time, and
consider weekends and potentially public regional holidays.
Regarding the technical actions: The branch name doesn't comply with the
existing naming convention (the branch naming pattern that JB used),
which is also required to later support semi-automatic releases
(discussed a couple months ago during a community sync call).
Considering that we do not seem to have a consensus on the content of
the 1.0 release, there are still 1.0-blockers and the wrong branch name,
I strongly prefer do delete that branch.
Regarding the release manager, I'm in favor of letting JB drive the
release process to ensure that things go smooth.
Related note: We already have quite a bunch of branches in the GH repo
whose meaning is not clear to me.
Robert
On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
> Also the
> last PPMC member's agreement on thread[1] happened 5 days ago, which passed
> the lazy consensus window. But I agreed it's nice to conclude a thread.
>
>
> The consensus in that thread was to skip the 0.10.0 release.
>
> From my POV an agreement to skip 0.10.0 does not mean that the scope for
> 1.0 is set and agreed upon.
>
> What I'm asking for is proactively engaging with the community before
> executing technical actions for a new release as opposed to informing after
> actions are taken.
>
> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>
> Thanks,
> Dmitri.
>
> On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com> wrote:
>
>> The branch name is "1.0.x".
>>
>> Where is this agreement recorded?
>>
>> Discussed multiple times with JB last Thursday(6/5/2025) and this
>> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead of a
>> blocker.
>>
>> As a matter of best practice, given the previous related discussion thread
>>> [1], it would have been nice to conclude it with a message about starting
>>> the 1.0 release process before actually cutting the branch.
>> We got consensus on thread[1]. The 1.0 release was also prepared way before
>> the thread. We will kick off 1.0 release even if 0.10 is not canceled. JB
>> and I discussed the parallel releasing option for both versions. Also the
>> last PPMC member's agreement on thread[1] happened 5 days ago, which passed
>> the lazy consensus window. But I agreed it's nice to conclude a thread.
>>
>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>
>> Yufei
>>
>>
>> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <di...@apache.org>
>> wrote:
>>
>>> I cut the 1.0.x branch yesterday morning.
>>>
>>>
>>> As a matter of best practice, given the previous related discussion
>> thread
>>> [1], it would have been nice to conclude it with a message about starting
>>> the 1.0 release process before actually cutting the branch.
>>>
>>> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>>>
>>> Thanks,
>>> Dmitri.
>>>
>>> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com> wrote:
>>>
>>>> Thanks everyone for the contribution. We've finally resolved all
>>>> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only cherry
>>>> pick bug fixes and license related commits to this branch starting now.
>>>>
>>>> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
>>>> best-to-have instead of a blocker per offline discussion,
>>>> https://github.com/apache/polaris/pull/1695.
>>>>
>>>> Yufei
>>>>
>>>>
>>>> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <er...@gmail.com>
>>>> wrote:
>>>>
>>>>> +1 to making 801 a blocker.
>>>>>
>>>>> Based on Alex's comments in 1799, it looks like the rotation is only
>>>>> happening in JdbcMetastoreManagerFactory? If so, I think we have a
>> very
>>>>> simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
>>>>>
>>>>> --EM
>>>>>
--
Robert Stupp
@snazy
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <di...@apache.org>.
Also the
last PPMC member's agreement on thread[1] happened 5 days ago, which passed
the lazy consensus window. But I agreed it's nice to conclude a thread.
The consensus in that thread was to skip the 0.10.0 release.
From my POV an agreement to skip 0.10.0 does not mean that the scope for
1.0 is set and agreed upon.
What I'm asking for is proactively engaging with the community before
executing technical actions for a new release as opposed to informing after
actions are taken.
[1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Thanks,
Dmitri.
On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com> wrote:
> The branch name is "1.0.x".
>
> Where is this agreement recorded?
>
> Discussed multiple times with JB last Thursday(6/5/2025) and this
> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead of a
> blocker.
>
> As a matter of best practice, given the previous related discussion thread
> > [1], it would have been nice to conclude it with a message about starting
> > the 1.0 release process before actually cutting the branch.
>
> We got consensus on thread[1]. The 1.0 release was also prepared way before
> the thread. We will kick off 1.0 release even if 0.10 is not canceled. JB
> and I discussed the parallel releasing option for both versions. Also the
> last PPMC member's agreement on thread[1] happened 5 days ago, which passed
> the lazy consensus window. But I agreed it's nice to conclude a thread.
>
> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>
> Yufei
>
>
> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <di...@apache.org>
> wrote:
>
> > I cut the 1.0.x branch yesterday morning.
> >
> >
> > As a matter of best practice, given the previous related discussion
> thread
> > [1], it would have been nice to conclude it with a message about starting
> > the 1.0 release process before actually cutting the branch.
> >
> > [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >
> > Thanks,
> > Dmitri.
> >
> > On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com> wrote:
> >
> > > Thanks everyone for the contribution. We've finally resolved all
> > > blockers[1]. I cut the 1.0.x branch yesterday morning. Will only cherry
> > > pick bug fixes and license related commits to this branch starting now.
> > >
> > > [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> > > best-to-have instead of a blocker per offline discussion,
> > > https://github.com/apache/polaris/pull/1695.
> > >
> > > Yufei
> > >
> > >
> > > On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <er...@gmail.com>
> > > wrote:
> > >
> > > > +1 to making 801 a blocker.
> > > >
> > > > Based on Alex's comments in 1799, it looks like the rotation is only
> > > > happening in JdbcMetastoreManagerFactory? If so, I think we have a
> very
> > > > simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
> > > >
> > > > --EM
> > > >
> > >
> >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <di...@apache.org>.
Discussed multiple times with JB last Thursday(6/5/2025) and this
Monday(6/9/2025), we agreed to consider it as a nice-to-have instead of a
blocker.
I'm sure none of JB's statements (even though I was not part of those
meetings, IIRC) implied that the agreement is community-wide.
The Apache Way is that "off-list discourse and transactions must be brought
on-list" [1]
[1] https://www.apache.org/theapacheway/
Cheers,
Dmitri.
On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <fl...@gmail.com> wrote:
> The branch name is "1.0.x".
>
> Where is this agreement recorded?
>
> Discussed multiple times with JB last Thursday(6/5/2025) and this
> Monday(6/9/2025), we agreed to consider it as a nice-to-have instead of a
> blocker.
>
> As a matter of best practice, given the previous related discussion thread
> > [1], it would have been nice to conclude it with a message about starting
> > the 1.0 release process before actually cutting the branch.
>
> We got consensus on thread[1]. The 1.0 release was also prepared way before
> the thread. We will kick off 1.0 release even if 0.10 is not canceled. JB
> and I discussed the parallel releasing option for both versions. Also the
> last PPMC member's agreement on thread[1] happened 5 days ago, which passed
> the lazy consensus window. But I agreed it's nice to conclude a thread.
>
> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>
> Yufei
>
>
> On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <di...@apache.org>
> wrote:
>
> > I cut the 1.0.x branch yesterday morning.
> >
> >
> > As a matter of best practice, given the previous related discussion
> thread
> > [1], it would have been nice to conclude it with a message about starting
> > the 1.0 release process before actually cutting the branch.
> >
> > [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
> >
> > Thanks,
> > Dmitri.
> >
> > On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com> wrote:
> >
> > > Thanks everyone for the contribution. We've finally resolved all
> > > blockers[1]. I cut the 1.0.x branch yesterday morning. Will only cherry
> > > pick bug fixes and license related commits to this branch starting now.
> > >
> > > [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> > > best-to-have instead of a blocker per offline discussion,
> > > https://github.com/apache/polaris/pull/1695.
> > >
> > > Yufei
> > >
> > >
> > > On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <er...@gmail.com>
> > > wrote:
> > >
> > > > +1 to making 801 a blocker.
> > > >
> > > > Based on Alex's comments in 1799, it looks like the rotation is only
> > > > happening in JdbcMetastoreManagerFactory? If so, I think we have a
> very
> > > > simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
> > > >
> > > > --EM
> > > >
> > >
> >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Yufei Gu <fl...@gmail.com>.
The branch name is "1.0.x".
Where is this agreement recorded?
Discussed multiple times with JB last Thursday(6/5/2025) and this
Monday(6/9/2025), we agreed to consider it as a nice-to-have instead of a
blocker.
As a matter of best practice, given the previous related discussion thread
> [1], it would have been nice to conclude it with a message about starting
> the 1.0 release process before actually cutting the branch.
We got consensus on thread[1]. The 1.0 release was also prepared way before
the thread. We will kick off 1.0 release even if 0.10 is not canceled. JB
and I discussed the parallel releasing option for both versions. Also the
last PPMC member's agreement on thread[1] happened 5 days ago, which passed
the lazy consensus window. But I agreed it's nice to conclude a thread.
[1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Yufei
On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <di...@apache.org>
wrote:
> I cut the 1.0.x branch yesterday morning.
>
>
> As a matter of best practice, given the previous related discussion thread
> [1], it would have been nice to conclude it with a message about starting
> the 1.0 release process before actually cutting the branch.
>
> [1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
>
> Thanks,
> Dmitri.
>
> On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com> wrote:
>
> > Thanks everyone for the contribution. We've finally resolved all
> > blockers[1]. I cut the 1.0.x branch yesterday morning. Will only cherry
> > pick bug fixes and license related commits to this branch starting now.
> >
> > [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> > best-to-have instead of a blocker per offline discussion,
> > https://github.com/apache/polaris/pull/1695.
> >
> > Yufei
> >
> >
> > On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <er...@gmail.com>
> > wrote:
> >
> > > +1 to making 801 a blocker.
> > >
> > > Based on Alex's comments in 1799, it looks like the rotation is only
> > > happening in JdbcMetastoreManagerFactory? If so, I think we have a very
> > > simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
> > >
> > > --EM
> > >
> >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <di...@apache.org>.
I cut the 1.0.x branch yesterday morning.
As a matter of best practice, given the previous related discussion thread
[1], it would have been nice to conclude it with a message about starting
the 1.0 release process before actually cutting the branch.
[1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Thanks,
Dmitri.
On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com> wrote:
> Thanks everyone for the contribution. We've finally resolved all
> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only cherry
> pick bug fixes and license related commits to this branch starting now.
>
> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> best-to-have instead of a blocker per offline discussion,
> https://github.com/apache/polaris/pull/1695.
>
> Yufei
>
>
> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <er...@gmail.com>
> wrote:
>
> > +1 to making 801 a blocker.
> >
> > Based on Alex's comments in 1799, it looks like the rotation is only
> > happening in JdbcMetastoreManagerFactory? If so, I think we have a very
> > simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
> >
> > --EM
> >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <dm...@dremio.com.INVALID>.
> I cut the 1.0.x branch yesterday morning
I do not see a "release/1.0.0" branch (which is a pattern used for previous
releases).
[1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
best-to-have instead of a blocker per offline discussion,
Where is this agreement recorded?
As for me, the proposed rename does make sense to do before 1.0.
[1] https://github.com/apache/polaris/pull/1695.
Cheers,
Dmitri.
On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <fl...@gmail.com> wrote:
> Thanks everyone for the contribution. We've finally resolved all
> blockers[1]. I cut the 1.0.x branch yesterday morning. Will only cherry
> pick bug fixes and license related commits to this branch starting now.
>
> [1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
> best-to-have instead of a blocker per offline discussion,
> https://github.com/apache/polaris/pull/1695.
>
> Yufei
>
>
> On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <er...@gmail.com>
> wrote:
>
> > +1 to making 801 a blocker.
> >
> > Based on Alex's comments in 1799, it looks like the rotation is only
> > happening in JdbcMetastoreManagerFactory? If so, I think we have a very
> > simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
> >
> > --EM
> >
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Yufei Gu <fl...@gmail.com>.
Thanks everyone for the contribution. We've finally resolved all
blockers[1]. I cut the 1.0.x branch yesterday morning. Will only cherry
pick bug fixes and license related commits to this branch starting now.
[1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
best-to-have instead of a blocker per offline discussion,
https://github.com/apache/polaris/pull/1695.
Yufei
On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <er...@gmail.com>
wrote:
> +1 to making 801 a blocker.
>
> Based on Alex's comments in 1799, it looks like the rotation is only
> happening in JdbcMetastoreManagerFactory? If so, I think we have a very
> simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
>
> --EM
>
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Eric Maynard <er...@gmail.com>.
+1 to making 801 a blocker.
Based on Alex's comments in 1799, it looks like the rotation is only
happening in JdbcMetastoreManagerFactory? If so, I think we have a very
simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
--EM
Re: [DISCUSS] Prepare for 1.0 Release
Posted by Dmitri Bourlatchkov <di...@apache.org>.
I re-opened [801] and labelled it as 1.0 blocker.
My rationale is that it is a degraded UX and in previous discussions on
this issue the consensus was that "it should not happen".
[801] https://github.com/apache/polaris/issues/801
Cheers,
Dmitri.
On Mon, Jun 2, 2025 at 5:22 PM Dmitri Bourlatchkov <di...@apache.org> wrote:
> Hi All,
>
> I've just added [1775] to the list of 1.0 blockers. My rationale:
>
> * As discussed in [1758], current configuration lookup methods have a
> certain API skew.
>
> Some methods have PolarisCallContext parameters, others
> RealmContext. PolarisCallContext implies a certain realm ID (e.g. it
> includes a BasePersistence, whose JDBC implementation is specific to a
> realm - it has a realm ID field), but it does not expose the realm ID for
> access to outside caller. As a result, this API makes it obscure how the
> realm ID is obtained for looking up configuration values. Is it the
> implicit realm ID in PolarisCallContext? Is it the realm ID from the
> Request Scope?
>
> * Given that some PRs and comments already bring up API backwards
> compatibility concerns (e.g. [1724]), I believe it is critical to sort out
> CDI context issues and configuration lookup APIs before 1.0 as it is a
> central piece of Polaris backend and affects many code areas.
>
> That said, I'm willing to participate in addressing [1175] ASAP.
>
> [1724] https://github.com/apache/polaris/pull/1724
> [1758] https://github.com/apache/polaris/pull/1758
> [1775] https://github.com/apache/polaris/issues/1775
>
> Cheers,
> Dmitri.
>
> On Thu, May 15, 2025 at 5:39 PM Yufei Gu <fl...@gmail.com> wrote:
>
>> Hi folks,
>>
>> Many users have been asking about the Polaris release, and I believe it's
>> critical to have a formal, production-ready 1.0 release ASAP. Thanks to
>> the
>> community’s hard work, we’re very close with a few remaining blockers we
>> need to resolve.
>>
>> To keep things moving, I scheduled a community meeting for the 1.0 release
>> next Monday at 9 AM PST. At the same time, sharing all issues marked with
>> 1.0 blocker. We could resolve them here if possible. Feel free to chime
>> in,
>> remove the blocker tag if you think it's not a blocker, or pick any up.
>> Thanks a lot in advance!
>>
>> Here is the list:
>>
>> - Add CI for Python code (
>> <https://github.com/apache/polaris/issues/1058>#1058),
>> - Polaris persistence concurrency issues (#777)
>> <https://github.com/apache/polaris/issues/777>
>> - Task handling is incomplete (#774)
>> <https://github.com/apache/polaris/issues/774>
>> - Generated files in regtests/client/python/polaris (#755)
>> <https://github.com/apache/polaris/issues/755>
>> - Resources not properly closed, resource & memory leaks (#563)
>> <https://github.com/apache/polaris/issues/563>
>> - Make Polaris safe against certain unparseable locations (#552)
>> <https://github.com/apache/polaris/issues/552>
>> - [BUG] Assumption that cache eviction does not happen (#544)
>> <https://github.com/apache/polaris/issues/544>
>>
>> To make it more interactive, you can also comment on the google
>> spreadsheet here:
>>
>> https://docs.google.com/spreadsheets/d/1GyLvp2cdYwioOsBwszNWiphZt_IIdo4LIfsZBFV88mc/edit?usp=sharing
>>
>> Yufei
>>
>