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