Hi

I will cherry pick on the 1.6.0 release branch.

Regards
JB

On Fri, Jun 26, 2026 at 9:02 PM Dmitri Bourlatchkov <[email protected]>
wrote:

> Hi All,
>
> I also propose to include [4884] in the next RC... If RC1 is built from the
> latest `main` this should happen automatically (the PR has already been
> merged).
>
> [4884] https://github.com/apache/polaris/pull/4884
>
> Cheers,
> Dmitri.
>
> On Wed, Jun 24, 2026 at 5:05 PM Dmitri Bourlatchkov <[email protected]>
> wrote:
>
> > Hi EJ,
> >
> > Thanks for cutting RC0!
> >
> > While it is unfortunate that RC0 had issues (with the Spark plugin IIRC),
> > now that some extra changes seem necessary anyway, I wonder if we could
> > include [4860] into RC1? WDYT?
> >
> > [4860] https://github.com/apache/polaris/pull/4860
> >
> > Thanks,
> > Dmitri.
> >
> > On Mon, Jun 22, 2026 at 1:16 PM EJ Wang <[email protected]>
> > wrote:
> >
> >> Hi all,
> >>
> >> Quick update on the Apache Polaris 1.6.0 branch cut.
> >>
> >> The release workflow/documentation updates that were called out earlier
> >> have now landed on main:
> >>
> >> - #4626: release-4 updates previous versioned-docs binary dist URLs to
> >> archive
> >> - #4650: release workflow 4 drops dist release SVN writes and documents
> >> the
> >> manual PMC dev -> release move
> >>
> >> I have not seen any additional 1.6.0 blockers or must-have PRs called
> out
> >> on this thread.
> >>
> >> The current main HEAD is green, and I plan to use it as the 1.6.0
> cutoff:
> >> *Add
> >> external Polaris server test manager (#4843)*
> >>
> >> Unless there are last-minute objections, I will proceed with creating
> the
> >> 1.6.0 release branch from this commit and start preparing the first
> >> release
> >> candidate.
> >>
> >> Thanks,
> >> -ej
> >>
> >> On Thu, Jun 11, 2026 at 5:09 PM EJ Wang <[email protected]
> >
> >> wrote:
> >>
> >> > Hi all,
> >> >
> >> > Quick update on the 1.6.0 branch cut:
> >> >
> >> >    - Adnan's requested release workflow fix, #4626, has now landed on
> >> >    main. Thanks Adnan and reviewers.
> >> >    - The current main HEAD is: InMemoryBufferEventListener: fix cache
> >> >    removal logic and flaky test (#4677
> >> >    <https://github.com/apache/polaris/pull/4677>)
> >> >    - I checked the current HEAD and the required checks are green. I
> >> have
> >> >    not seen any other PRs called out on this thread as must-have
> >> blockers for
> >> >    1.6.0.
> >> >
> >> > The one remaining release-process PR I am watching is #4650, which
> >> > documents/moves the dist dev -> dist release SVN steps to a manual PMC
> >> > action after the vote. It is mergeable and green, but still pending
> >> > review/merge. If #4650 lands shortly, I plan to use the main commit
> >> > immediately after #4650 as the final 1.6.0 cutoff. Otherwise, I plan
> to
> >> > proceed from the current green main HEAD above and keep coordinating
> the
> >> > manual post-vote steps with PMC help.
> >> >
> >> > Please call out any objections or must-have PRs soon; otherwise I will
> >> > proceed with preparing the 1.6.0 release branch/RC from that cutoff.
> >> >
> >> > Thanks,
> >> > -ej
> >> >
> >> > On Tue, Jun 9, 2026 at 12:44 PM Jean-Baptiste Onofré <[email protected]
> >
> >> > wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> Thanks to both of you for the review and updates. I will perform a
> >> pass on
> >> >> the PR now so we can move forward with the 1.6.0 release as planned.
> >> >>
> >> >> Regards,
> >> >> JB
> >> >>
> >> >>
> >> >> On Tue, Jun 9, 2026 at 6:33 PM EJ Wang <
> [email protected]
> >> >
> >> >> wrote:
> >> >>
> >> >> > Thanks Adnan! this makes sense to get in before the branch cut. The
> >> >> > workflow placement looks good to me, and updating the superseded
> >> >> versioned
> >> >> > docs during release publication should prevent old binary
> >> distribution
> >> >> > links from breaking after cleanup.
> >> >> >
> >> >> > I left one small question about preserving the incubator archive
> path
> >> >> for
> >> >> > older incubating release docs. Otherwise LGTM.
> >> >> >
> >> >> > -ej
> >> >> >
> >> >> > On Mon, Jun 8, 2026 at 4:00 PM Adnan Hemani via dev <
> >> >> > [email protected]>
> >> >> > wrote:
> >> >> >
> >> >> > > I would say, we should wait for this PR to land before we branch
> >> cut.
> >> >> > This
> >> >> > > will help us solve an issue we've had for a while that no one
> >> >> reported:
> >> >> > > https://github.com/apache/polaris/pull/4626/changes. If we don't
> >> take
> >> >> > this
> >> >> > > PR into 1.6.0, then fixing this issue will likely have to wait
> >> until
> >> >> > 1.7.0
> >> >> > > - which keeps all historical release links broken in the
> meantime.
> >> >> > >
> >> >> > > Best,
> >> >> > > Adnan Hemani
> >> >> > >
> >> >> > > On Mon, Jun 8, 2026 at 3:16 PM EJ Wang <
> >> >> [email protected]>
> >> >> > > wrote:
> >> >> > >
> >> >> > > > Thanks, JB! Reviewed and approved.
> >> >> > > >
> >> >> > > > All,
> >> >> > > > I have not seen any specific must-have PRs or release blockers
> >> >> called
> >> >> > out
> >> >> > > > for 1.6.0.
> >> >> > > >
> >> >> > > > Unless there are objections, I plan to use the current main
> >> branch
> >> >> > after
> >> >> > > > the release workflow/documentation update in #4650 lands as the
> >> >> cutoff
> >> >> > > > point for 1.6.0. Concretely, I will cut the release branch from
> >> the
> >> >> > main
> >> >> > > > commit immediately after #4650 is merged.
> >> >> > > >
> >> >> > > > If anyone has a must-have PR that should be included in 1.6.0,
> >> >> please
> >> >> > > call
> >> >> > > > it out on this thread by <date/time>. Otherwise, I will proceed
> >> with
> >> >> > that
> >> >> > > > cutoff and start preparing the first RC.
> >> >> > > >
> >> >> > > > Thanks,
> >> >> > > > -ej
> >> >> > > >
> >> >> > > > On Mon, Jun 8, 2026 at 9:21 AM Jean-Baptiste Onofré <
> >> >> [email protected]>
> >> >> > > > wrote:
> >> >> > > >
> >> >> > > > > Hi
> >> >> > > > >
> >> >> > > > > Following this discussion, I updated the release process and
> >> >> > > > documentation:
> >> >> > > > > https://github.com/apache/polaris/pull/4650
> >> >> > > > >
> >> >> > > > > Regards
> >> >> > > > > JB
> >> >> > > > >
> >> >> > > > > On Mon, Jun 1, 2026 at 11:02 PM EJ Wang <
> >> >> > > [email protected]>
> >> >> > > > > wrote:
> >> >> > > > >
> >> >> > > > > > Thanks Dmitri, Yufei, and JB.
> >> >> > > > > >
> >> >> > > > > > I will keep moving forward with the June 26 target then.
> >> >> > > > > >
> >> >> > > > > > Thanks JB and Yufei for offering to help with the PMC-only
> >> >> > post-vote
> >> >> > > > > steps.
> >> >> > > > > > I will coordinate with you when we get closer to the
> >> >> > RC/vote/publish
> >> >> > > > > > stages.
> >> >> > > > > >
> >> >> > > > > > For #4579, I will add it to the release tracker and watch
> the
> >> >> > related
> >> >> > > > > PRs.
> >> >> > > > > > Given the discussion so far, I will treat it as something
> we
> >> >> should
> >> >> > > try
> >> >> > > > > to
> >> >> > > > > > resolve before cutting the RC, but not necessarily a hard
> >> >> blocker
> >> >> > > > unless
> >> >> > > > > > others feel strongly that it should block 1.6.0.
> >> >> > > > > >
> >> >> > > > > > Thanks,
> >> >> > > > > > -ej
> >> >> > > > > >
> >> >> > > > > > On Mon, Jun 1, 2026 at 9:43 AM Yufei Gu <
> >> [email protected]>
> >> >> > > wrote:
> >> >> > > > > >
> >> >> > > > > > > Thanks for filing the issue. It's great to have it. I'm
> OK
> >> to
> >> >> > > > consider
> >> >> > > > > > 4579
> >> >> > > > > > > either a blocker or non-blocker, as we have made releases
> >> >> without
> >> >> > > it
> >> >> > > > > > > multiple times. I can also help with PMC duty.
> >> >> > > > > > >
> >> >> > > > > > > Yufei
> >> >> > > > > > >
> >> >> > > > > > >
> >> >> > > > > > > On Sun, May 31, 2026 at 10:48 PM Jean-Baptiste Onofré <
> >> >> > > > [email protected]
> >> >> > > > > >
> >> >> > > > > > > wrote:
> >> >> > > > > > >
> >> >> > > > > > > > Hi EJ,
> >> >> > > > > > > >
> >> >> > > > > > > > This plan sounds good to me. Thanks for volunteering!
> >> >> > > > > > > >
> >> >> > > > > > > > I have created
> >> >> https://github.com/apache/polaris/issues/4579,
> >> >> > as
> >> >> > > > the
> >> >> > > > > > > > release workflow and documentation need to be updated.
> I
> >> am
> >> >> > > > currently
> >> >> > > > > > > > working on this, and it should be considered a release
> >> >> blocker.
> >> >> > > > > > > >
> >> >> > > > > > > > Additionally, you will need the assistance of a PMC
> >> member
> >> >> to
> >> >> > > > > complete
> >> >> > > > > > > > the post-vote release steps. I will be happy to help
> you
> >> >> with
> >> >> > > that
> >> >> > > > > > > > process.
> >> >> > > > > > > >
> >> >> > > > > > > > Regards,
> >> >> > > > > > > > JB
> >> >> > > > > > > >
> >> >> > > > > > > > On Fri, May 29, 2026 at 9:16 PM EJ Wang <
> >> >> > > > > > [email protected]>
> >> >> > > > > > > > wrote:
> >> >> > > > > > > > >
> >> >> > > > > > > > > Hi all,
> >> >> > > > > > > > >
> >> >> > > > > > > > > I would like to volunteer as the release manager for
> >> >> Apache
> >> >> > > > Polaris
> >> >> > > > > > > > 1.6.0.
> >> >> > > > > > > > >
> >> >> > > > > > > > > I am thinking about targeting Friday, June 26, 2026
> for
> >> >> the
> >> >> > > > > release,
> >> >> > > > > > > > > assuming the community agrees and we do not have
> >> blocking
> >> >> > > issues
> >> >> > > > by
> >> >> > > > > > > then.
> >> >> > > > > > > > >
> >> >> > > > > > > > > To start planning, could folks please share if there
> >> are
> >> >> any:
> >> >> > > > > > > > > - release blockers for 1.6.0
> >> >> > > > > > > > > - must-have PRs that should be included
> >> >> > > > > > > > > - timing concerns around the proposed date
> >> >> > > > > > > > > - areas where you would like to help validate the
> >> release
> >> >> > > > candidate
> >> >> > > > > > > > >
> >> >> > > > > > > > > Based on the previous 1.5.0 release flow, my rough
> plan
> >> >> is:
> >> >> > > > > > > > > - collect blockers and must-have PRs over the next
> >> couple
> >> >> of
> >> >> > > > weeks
> >> >> > > > > > > > > - start converging the scope around mid-June
> >> >> > > > > > > > > - prepare the changelog/release notes and cut the
> >> first RC
> >> >> > > around
> >> >> > > > > > June
> >> >> > > > > > > 20
> >> >> > > > > > > > > - keep the vote open for at least 72 hours
> >> >> > > > > > > > > - publish and announce the release around June 26 if
> >> the
> >> >> vote
> >> >> > > > > passes
> >> >> > > > > > > > >
> >> >> > > > > > > > > I will also keep an eye on release workflow/artifact
> >> >> > > validation,
> >> >> > > > > > > > including
> >> >> > > > > > > > > source artifacts, Maven artifacts, Docker images,
> Helm
> >> >> chart,
> >> >> > > > > Python
> >> >> > > > > > > > > package, and the website/downloads page.
> >> >> > > > > > > > >
> >> >> > > > > > > > > Please let me know if this timeline sounds
> reasonable,
> >> or
> >> >> if
> >> >> > > > there
> >> >> > > > > > are
> >> >> > > > > > > > > concerns I should account for.
> >> >> > > > > > > > >
> >> >> > > > > > > > > Thanks,
> >> >> > > > > > > > > -ej
> >> >> > > > > > > >
> >> >> > > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >> >
> >>
> >
>

Reply via email to