We should have all the post-graduation changes in [3830], so we get a 1.4.0 release without the -incubating suffix. I added that PR to the 1.4.0 milestone.
[3830] https://github.com/apache/polaris/pull/3830 On Thu, Feb 19, 2026 at 7:46 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi > > I will take a look at Anand's PR. It would be great if we can include > it in the 1.4.0 release. > > As we graduated now, I propose to take the time to prepare the 1.4.0 > release for post migration: > - remove incubating from the release scripts and name/version > (including README files, etc) > - updating the Gradle configuration > - remove the DISCLAIMER file > - update the NOTICE (removing the incubation) > > The website can be updated in a second step (removing Incubator > mention, updating documentation, ...). > > I think it can be done pretty quickly. > > What about being ready for 1.4.0 by the end of this week ? > > Regards > JB > > On Thu, Feb 19, 2026 at 2:00 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > > Hi All, > > > > I reviewed Anand's PR [3385]. Aside from a couple of remaining CDI > concerns > > it looks good to me. I think we can get it to a mergeable state this > week. > > > > Other reviews are welcome too, of course. > > > > [3385] https://github.com/apache/polaris/pull/3385 > > > > Cheers, > > Dmitri. > > > > On Wed, Feb 18, 2026 at 6:00 PM Anand Kumar Sankaran via dev < > > [email protected]> wrote: > > > > > Hi all > > > > > > If possible, please consider > https://github.com/apache/polaris/pull/3385 > > > for 1.4.0. I have been working on it since early January. We merged > the > > > two PRs needed for this already. This will help with some of the > auditing > > > reports we need to fulfill. > > > > > > Thanks. > > > > > > — > > > Anand > > > > > > > > > From: Dmitri Bourlatchkov <[email protected]> > > > Date: Tuesday, February 17, 2026 at 11:48 AM > > > To: [email protected] <[email protected]> > > > Subject: Re: [DISCUSSION] Apache Polaris 1.4.0-incubating Branch Cut > Thread > > > > > > This Message Is From an External Sender > > > This message came from outside your organization. > > > Report Suspicious< > > > > https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZAGr2cumYdhq2W2sFOTy-HdpkeXbxtpOetuJuikM0YWnGuW19JDGkalMmWH85CNONgufXmlw8sHY9e9S3pWVPi_EZ5dJhNrp0m_nwyqFtwN9f9IH1Kra10wjIBgk$ > > > > > > > > > > > > > Hi Yufei, > > > > > > I'm open to continuing the discussion on PR 3395 if needed, but I don't > > > think it is a blocker for 1.4.0. > > > > > > > > > It is not a blocker from the release perspective, but [3395] makes the > > > NoSQL Persistence story "complete" from the end user's perspective. > > > > > > Given that everyone is in agreement with continuing discussions and > > > improvements in the Admin Tool, would you mind merging [3395] > specifically > > > to provide a full solution to end users in 1.4.0 and adjusting on main > with > > > additional proposals / considerations later? > > > > > > I'm just trying to understand if there may be any disadvantage to > merging > > > it now. The possible "convenience" or "confusion" aspects can be > discussed > > > in docs and in any case are outweighed (from my POV) by the fact that > users > > > get a usable maintenance tool in the same release as the backend that > needs > > > this tool. My impression from previous discussions about this PR is > that > > > the majority of the community is fine with having it in the Admin > Tool, at > > > least as the next step in the evolution of the project. > > > > > > [3395] > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3395__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sPI-AeozQ$ > > > > > > Thanks, > > > Dmitri. > > > > > > On Tue, Feb 17, 2026 at 2:17 PM Yufei Gu <[email protected]> wrote: > > > > > > > +1 on what Adnan and JB proposed. > > > > > > > > Hi Dmitri, > > > > > > > > We need a few followups for PR 3409, like CLI and doc changes, but I > > > think > > > > it's fine to include it in 1.4.0 as it is guarded by the feature > flag. > > > > > > > > I'm open to continuing the discussion on PR 3395 if needed, but I > don't > > > > think it is a blocker for 1.4.0. > > > > > > > > Yufei > > > > > > > > > > > > On Tue, Feb 17, 2026 at 9:32 AM Dmitri Bourlatchkov < > [email protected]> > > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > Any concerns with merging [3409] before 1.4.0? > > > > > > > > > > Note: the new functionality is covered by a feature flag, which is > off > > > by > > > > > default. > > > > > > > > > > [3409] > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3409__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sMh5DJ48w$ > > > > > > > > > > Thanks, > > > > > Dmitri. > > > > > > > > > > On Mon, Feb 16, 2026 at 9:37 PM Adnan Hemani via dev < > > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I've gone through the GH issues and PRs tagged to the 1.4.0 > label and > > > > > would > > > > > > like to make the following recommendations for a potential Apache > > > > Polaris > > > > > > 1.4.0 release branch cut on (tentatively) 2026-02-23. > > > > > > > > > > > > Please reply to this thread prior to that date if there is any > > > > feedback, > > > > > > comments, and/or concerns so that we can get community consensus > > > before > > > > > we > > > > > > proceed with the release. If there are no replies to this email, > the > > > > > 1.4.0 > > > > > > release branch will be cut on 2026-02-23. > > > > > > > > > > > > Open Issues (Recommendation in []): > > > > > > * [PUNT] #538 < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/issues/538__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sO-t_pD3A$ > >: > > > Table > > > > > > Maintenance Support in Polaris > > > > > > * No major work in progress to justify delaying the release. > > > > > > > > > > > > * [CLOSE] #550 < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/issues/550__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sMXDx_5Qg$ > >: > > > Support > > > > > for > > > > > > GCP service account impersonation. > > > > > > * I will ping Michael to do this when he is back from > vacation. > > > > > > > > > > > > * [CLOSE] #552 < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/issues/552__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sMHJ-GYCg$ > >: > > > Safety > > > > > > against unparseable locations. > > > > > > * I believe all the work has been completed for this. > Dmitri, can > > > > you > > > > > > please confirm? (Will follow up offline as well) > > > > > > > > > > > > * [DISCUSS] #650 < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/issues/650__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sPo8UrF-w$ > > > > > / > > > > #3395 > > > > > > < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3395__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sPI-AeozQ$ > >: > > > MongoDB Persistence > > > > > Backend > > > > > > * It seems that discussions are still active and ongoing, and > > > there > > > > > is > > > > > > disagreement behind getting the change into Admin Tools while the > > > core > > > > > > functionality is merged already. I can see the arguments from > both > > > > sides > > > > > to > > > > > > push 1.4.0 without the Admin Tools change OR to hold the release > > > until > > > > > > there is agreement on these last bit of changes. What are the > > > > community's > > > > > > thoughts? Default option (if no one chimes in): we will push the > > > > release > > > > > > as-is on the 23rd. > > > > > > > > > > > > * [PUNT] #2671 < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/issues/2671__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sNv0MfBlA$ > >: > > > DB > > > > > Schema > > > > > > Migration Between Releases > > > > > > * No major work in progress to justify delaying the release. > > > > > > > > > > > > * [PUNT] #3685 < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/issues/3685__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sPAon6LaQ$ > > > >: > > > > > > `Create_Namespace` SQL Optimization > > > > > > * While there is traction, we may still be too far from a > > > > load-tested > > > > > > fix. This should be a high priority for 1.5.0. > > > > > > > > > > > > Open PRs: > > > > > > > > > > > > * [PUNT] #2180 < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/2180__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sOIMWeO6A$ > >: > > > Async & > > > > > > reliable tasks API, SPI, Store interfaces > > > > > > * PR is not very active over the last few weeks and does not > have > > > > > > enough active reviewers to see a strong path forward for merging > in > > > the > > > > > > next week or so. > > > > > > > > > > > > * [PUNT] #3256 < > > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3256__;!!Iz9xO38YGHZK!82Qo7hkJMYjRxc76YecxUhMwcBFlJB2Tl_2FL6ZIf_CrP16zl9imCNQT2CpL0QK9YGi6vudG-sNwWK6P6g$ > >: > > > Object > > > > > > Storage Operations > > > > > > * From the ML, it seems that there are still two rival > proposals > > > > that > > > > > > are attempting to solve similar issues. My recommendation is to > > > unstick > > > > > > this discussion from the 1.4.0 release to give proper time for > the > > > > > > discussion to resolve. > > > > > > > > > > > > When commenting, please reference the GH Issue/PR number so that > we > > > are > > > > > > clear on what is being discussed :) > > > > > > > > > > > > Best, > > > > > > Adnan Hemani > > > > > > > > > > > > > > > > > > > > > >
