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é <j...@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 <flyrain...@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 <flyrain...@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.mayn...@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 > >
