Unless there are any blockers, planning to prepare RC sometime next week.
On Wed, Sep 3, 2025 at 6:30 PM Viraj Jasani <vjas...@apache.org> wrote: > Hadoop release is done. > > > On Wed, Aug 20, 2025 at 9:40 PM Istvan Toth <st...@cloudera.com.invalid> > wrote: > >> Perhaps consider waiting for Hadoop 3.4.2. >> It's already in the RC phase. >> Stoty >> >> On Tue, Aug 12, 2025 at 7:22 AM Viraj Jasani <vjas...@apache.org> wrote: >> >> > We are getting closer. I am planning to get in a couple of Jiras >> (Segment >> > scan, thread pool tunings for uncovered index and view creation perf >> > improvements) and we should be hopefully ready to start 5.3.0 release >> next >> > week. >> > >> > Please let me know if you have any critical changes to incorporate into >> > 5.3.0 release. >> > >> > >> > On Sun, Jul 27, 2025 at 11:28 PM Istvan Toth <st...@cloudera.com.invalid >> > >> > wrote: >> > >> > > Thank you Viraj. >> > > >> > > https://issues.apache.org/jira/browse/PHOENIX-7668 is for the 2.6.3 >> > > update. >> > > I have not yet committed that, because of the test hangs with 2.6. >> > (though >> > > I'm pretty sure that those are not related to the 2.6.3 update) >> > > I know you are investigating this. >> > > >> > > Just opened https://issues.apache.org/jira/browse/PHOENIX-7681 for >> the >> > > 2.5.12 update. >> > > >> > > I'm not sure about updating the default. >> > > My default stance is to use the current HBase "stable" release line, >> > which >> > > is 2.5. >> > > On the other hand, it is expected that HBase will change the stable to >> > 2.6 >> > > in the not too distant future, >> > > and releasing 5.3 with the 2.6 default will avoid having to change the >> > > default in a patch release. >> > > >> > > I don't have a strong opinion either way. >> > > >> > > >> > > >> > > >> > > On Sun, Jul 27, 2025 at 8:24 AM Viraj Jasani <vjas...@apache.org> >> wrote: >> > > >> > > > We have completed all the work mentioned on this thread, but please >> > > remind >> > > > me if I am missing something. We also had tons of improvements, >> > features >> > > > and fixes done for 5.3.0 release. >> > > > >> > > > We are almost there to start 5.3.0 release. Given that we have had >> > recent >> > > > HBase releases on 2.5 and 2.6 release lines, would someone like to >> > > > volunteer to upgrade the versions in Phoenix master branch? >> > > > >> > > > We can also use 2.6 profile by default. >> > > > >> > > > >> > > > On Mon, Apr 28, 2025 at 11:49 PM Istvan Toth >> > <st...@cloudera.com.invalid >> > > > >> > > > wrote: >> > > > >> > > > > I'll start the thread, Viraj. >> > > > > >> > > > > On Tue, Apr 29, 2025 at 4:21 AM Viraj Jasani <vjas...@apache.org> >> > > wrote: >> > > > > >> > > > > > I think we can remove hbase 2.4 profile and compat module for >> 5.3.0 >> > > > > > release. >> > > > > > Any volunteers to start separate thread to get consensus and >> work >> > on >> > > > > > removing the profile? >> > > > > > >> > > > > > >> > > > > > On Thu, Apr 24, 2025 at 3:11 PM Viraj Jasani < >> vjas...@apache.org> >> > > > wrote: >> > > > > > >> > > > > > > > Hbase 2.4.x has been EOL for some time, we could drop >> support >> > for >> > > > it >> > > > > in >> > > > > > > 5.3. >> > > > > > > Sure, no strong opinion either way. We could also keep it as >> the >> > > last >> > > > > > > release, or just remove it now. >> > > > > > > >> > > > > > > > I agree, but both the Spotless reformat and the HBase 3.0 >> > > > pre-patches >> > > > > > are >> > > > > > > > ready, >> > > > > > > > and could be merged within a week, so I don't see this as >> > > blocking, >> > > > > > > rather >> > > > > > > > as finishing >> > > > > > > > projects that have been languishing for 6+ months. >> > > > > > > >> > > > > > > That's a reasonable point, however I am mostly worried about >> the >> > > > amount >> > > > > > of >> > > > > > > code changes and the num of features that we have for 5.3.0. >> > > > > Backtracking >> > > > > > > the change history, keeping track with 5.2 for backward >> > > compatibility >> > > > > etc >> > > > > > > might become painful. >> > > > > > > I still think we should wait for both HBase 3.0 support and >> > > spotless >> > > > > > > format changes for master branch only and not include 5.3. >> > > > > > > >> > > > > > > Let's hear from others also before we make the final >> decision? :) >> > > > > > > >> > > > > > > >> > > > > > > On Wed, Apr 23, 2025 at 10:37 PM Istvan Toth >> > > > > <st...@cloudera.com.invalid >> > > > > > > >> > > > > > > wrote: >> > > > > > > >> > > > > > >> We should also consider HBase 2.x version support for 5.3. >> > > > > > >> >> > > > > > >> Hbase 2.4.x has been EOL for some time, we could drop support >> > for >> > > it >> > > > > in >> > > > > > >> 5.3. >> > > > > > >> >> > > > > > >> >> > > > > > >> On Thu, Apr 24, 2025 at 7:32 AM Istvan Toth < >> st...@cloudera.com >> > > >> > > > > wrote: >> > > > > > >> >> > > > > > >> > Given that HBase 3.0.0 is not released yet, only beta-1 is >> > > > released >> > > > > so >> > > > > > >> far, >> > > > > > >> >> I believe we should not block Phoenix 5.3.0 for this. >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > I agree, but both the Spotless reformat and the HBase 3.0 >> > > > > pre-patches >> > > > > > >> are >> > > > > > >> > ready, >> > > > > > >> > and could be merged within a week, so I don't see this as >> > > > blocking, >> > > > > > >> rather >> > > > > > >> > as finishing >> > > > > > >> > projects that have been languishing for 6+ months. >> > > > > > >> > >> > > > > > >> > >> > > > > > >> >> Ideally, we would like Phoenix 6.0.0 major release with >> HBase >> > > > 3.0.0 >> > > > > > >> >> release >> > > > > > >> >> rather than Phoenix 5.4.0. This is what we have followed >> for >> > > > HBase >> > > > > 2 >> > > > > > >> >> release as well. WDYT? >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > I'm neutral on what we call the next release. 6.0.0 may be >> > > better >> > > > > for >> > > > > > >> > marketing. >> > > > > > >> > >> > > > > > >> > The important difference between the HBase 1->2 and 2->3 >> > > > transition >> > > > > > is >> > > > > > >> > that HBase 3 only breaks >> > > > > > >> > API compatibility WRT protobuf 2.5. >> > > > > > >> > >> > > > > > >> > While it was not feasible to support HBase 1.x and 2.x from >> > the >> > > > same >> > > > > > >> > Phoenix branch, >> > > > > > >> > it is perfectly feasible (if a bit awkward) to support >> HBase >> > 2.x >> > > > and >> > > > > > 3.x >> > > > > > >> > from the same branch, >> > > > > > >> > in fact my WIP branch does just that. >> > > > > > >> > >> > > > > > >> > Because of this, we can avoid having to maintain separate >> > > branches >> > > > > for >> > > > > > >> > HBase 2.x and 3.x, and treat 3.0 >> > > > > > >> > just as we do treat a new 2.x release, adding support for >> it >> > > > without >> > > > > > >> > breaking the existing 2.x releases. >> > > > > > >> > >> > > > > > >> > The current patches are fully compatible with HBase 2.x, >> they >> > > are >> > > > > just >> > > > > > >> > replacing HBase 1.x APIs >> > > > > > >> > that have slipped by the previous API migration attempts. >> > > > > > >> > >> > > > > > >> > For now, >> > > > > > >> >> keeping track of dev changes among 5.x branches would be >> > really >> > > > > > helpful >> > > > > > >> >> because we have tons of features for 5.3 release, I wish >> we >> > > could >> > > > > > have >> > > > > > >> >> done >> > > > > > >> >> 6.0.0 right away but let's wait for HBase 3.0.0 for it at >> > > least. >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > Backports are also my main concern. >> > > > > > >> > Actually, that's why I'm pushing for the spotless reformat >> > now. >> > > > > > >> > If we do it now, then master and 5.3 won't differ, and we >> can >> > > > follow >> > > > > > up >> > > > > > >> > with the same reformat for 5.2 and even 5.1. >> > > > > > >> > >> > > > > > >> > I'm aware that this will be an issue when backporting to >> > > > > > >> > private/downstream branches, but >> > > > > > >> > that will be true whenever we do the reformat, and we need >> to >> > > rip >> > > > > the >> > > > > > >> > band-aid off at some point. >> > > > > > >> > >> > > > > > >> > The same is true for the pre HBase 3.0 patches, if we merge >> > them >> > > > > now, >> > > > > > >> then >> > > > > > >> > at least this will be both in >> > > > > > >> > master and 5.3, and is one less thing to get in the way >> when >> > > > > > >> backporting. >> > > > > > >> > >> > > > > > >> > Istvan >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > On Wed, Apr 23, 2025 at 8:39 PM Viraj Jasani < >> > > vjas...@apache.org> >> > > > > > >> wrote: >> > > > > > >> > >> > > > > > >> >> Thanks for bringing this to the attention, Istvan! >> > > > > > >> >> >> > > > > > >> >> Given that HBase 3.0.0 is not released yet, only beta-1 is >> > > > released >> > > > > > so >> > > > > > >> >> far, >> > > > > > >> >> I believe we should not block Phoenix 5.3.0 for this. >> > > > > > >> >> Even if HBase 3.0.0 gets released soon, I still believe it >> > > makes >> > > > > more >> > > > > > >> >> sense >> > > > > > >> >> to have the above PRs merged after cutting 5.3 branch. >> > > > > > >> >> >> > > > > > >> >> A couple of proposals: >> > > > > > >> >> >> > > > > > >> >> - Once the 5.3 branch is created from master, we should >> > also >> > > > > > create >> > > > > > >> >> branch-5 or 5.x as the top level release branch for 5.x >> > > > > releases. >> > > > > > >> >> - master branch should start with the 6.0.0 dev >> version. >> > > > > > >> >> >> > > > > > >> >> Ideally, we would like Phoenix 6.0.0 major release with >> HBase >> > > > 3.0.0 >> > > > > > >> >> release >> > > > > > >> >> rather than Phoenix 5.4.0. This is what we have followed >> for >> > > > HBase >> > > > > 2 >> > > > > > >> >> release as well. WDYT? >> > > > > > >> >> >> > > > > > >> >> > The other major outstanding issue is the spotless >> reformat. >> > > > > > >> >> I think we should do that before branching, otherwise it's >> > > just a >> > > > > lot >> > > > > > >> of >> > > > > > >> >> extra work to do that twice. >> > > > > > >> >> >> > > > > > >> >> The spotless work also would benefit well for 6.0.0 >> release? >> > > For >> > > > > now, >> > > > > > >> >> keeping track of dev changes among 5.x branches would be >> > really >> > > > > > helpful >> > > > > > >> >> because we have tons of features for 5.3 release, I wish >> we >> > > could >> > > > > > have >> > > > > > >> >> done >> > > > > > >> >> 6.0.0 right away but let's wait for HBase 3.0.0 for it at >> > > least. >> > > > > > >> >> >> > > > > > >> >> I am planning to cut 5.3 branch soon after PHOENIX-7587 >> > > > > > >> >> <https://issues.apache.org/jira/browse/PHOENIX-7587> and >> > > > > > PHOENIX-7573 >> > > > > > >> >> <https://issues.apache.org/jira/browse/PHOENIX-7573> are >> > > merged, >> > > > > > >> >> hopefully >> > > > > > >> >> within a week. >> > > > > > >> >> >> > > > > > >> >> >> > > > > > >> >> On Tue, Apr 22, 2025 at 1:01 AM Istvan Toth >> > > > > > <st...@cloudera.com.invalid >> > > > > > >> > >> > > > > > >> >> wrote: >> > > > > > >> >> >> > > > > > >> >> > The big feature I'm tracking is HBase 3.0 support. >> > > > > > >> >> > >> > > > > > >> >> > I'm fine with releasing 5.3.0 before HBase 3.0 is out, >> but >> > > then >> > > > > we >> > > > > > >> >> should >> > > > > > >> >> > be prepared to either add HBase 3 support in a >> > > > > > >> >> > patch release, or release 5.4.0 relatively quickly after >> > 3.0. >> > > > > > >> >> > (Summer/Autumn-ish) >> > > > > > >> >> > >> > > > > > >> >> > There are still three HBase 3.0 preparation patches by >> me >> > and >> > > > > > Villo, >> > > > > > >> >> which >> > > > > > >> >> > IMO should be in 5.3.0, otherwise backports will >> > > > > > >> >> > be harder than they should be. These have been waiting >> for >> > > > review >> > > > > > for >> > > > > > >> >> some >> > > > > > >> >> > months, If I can't find anyone to review them, >> > > > > > >> >> > then I will self-review, as technically their current >> > > iteration >> > > > > was >> > > > > > >> >> already >> > > > > > >> >> > rebased/re-worked by Villo. >> > > > > > >> >> > >> > > > > > >> >> > https://github.com/apache/phoenix/pull/2035 >> > > > > > >> >> > https://github.com/apache/phoenix/pull/2036 >> > > > > > >> >> > https://github.com/apache/phoenix/pull/2038 >> > > > > > >> >> > >> > > > > > >> >> > The other major outstanding issue is the spotless >> reformat. >> > > > > > >> >> > I think we should do that before branching, otherwise >> it's >> > > > just a >> > > > > > >> lot of >> > > > > > >> >> > extra work to do that twice. >> > > > > > >> >> > >> > > > > > >> >> > (The spotless reformat, and the big outstanding HBase >> 3.0 >> > > > > > preparation >> > > > > > >> >> > patches are another problem, as >> > > > > > >> >> > it would be a lot of work to rebase them after the >> > reformat) >> > > > > > >> >> > >> > > > > > >> >> > >> > > > > > >> >> > Istvan >> > > > > > >> >> > >> > > > > > >> >> > >> > > > > > >> >> > >> > > > > > >> >> > On Fri, Apr 18, 2025 at 2:06 AM Viraj Jasani < >> > > > vjas...@apache.org >> > > > > > >> > > > > > >> >> wrote: >> > > > > > >> >> > >> > > > > > >> >> > > Hi, >> > > > > > >> >> > > >> > > > > > >> >> > > I am looking forward to creating the 5.3 branch from >> the >> > > > master >> > > > > > >> branch >> > > > > > >> >> > > sometime next week. >> > > > > > >> >> > > >> > > > > > >> >> > > We have many large changes in the master branch. While >> > > > majority >> > > > > > >> >> features >> > > > > > >> >> > > are hidden behind flags, it is important to ensure we >> > have >> > > a >> > > > > > smooth >> > > > > > >> >> > > release. >> > > > > > >> >> > > >> > > > > > >> >> > > Please discuss here if there are any big changes you >> are >> > > > > planning >> > > > > > >> to >> > > > > > >> >> > > include with the 5.3.0 release. >> > > > > > >> >> > > >> > > > > > >> >> > >> > > > > > >> >> > >> > > > > > >> >> > -- >> > > > > > >> >> > *István Tóth* | Sr. Staff Software Engineer >> > > > > > >> >> > *Email*: st...@cloudera.com >> > > > > > >> >> > cloudera.com <https://www.cloudera.com> >> > > > > > >> >> > [image: Cloudera] <https://www.cloudera.com/> >> > > > > > >> >> > [image: Cloudera on Twitter] < >> https://twitter.com/cloudera >> > > >> > > > > > [image: >> > > > > > >> >> > Cloudera on Facebook] < >> https://www.facebook.com/cloudera> >> > > > > [image: >> > > > > > >> >> Cloudera >> > > > > > >> >> > on LinkedIn] <https://www.linkedin.com/company/cloudera >> > >> > > > > > >> >> > ------------------------------ >> > > > > > >> >> > ------------------------------ >> > > > > > >> >> > >> > > > > > >> >> >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > -- >> > > > > > >> > *István Tóth* | Sr. Staff Software Engineer >> > > > > > >> > *Email*: st...@cloudera.com >> > > > > > >> > cloudera.com <https://www.cloudera.com> >> > > > > > >> > [image: Cloudera] <https://www.cloudera.com/> >> > > > > > >> > [image: Cloudera on Twitter] <https://twitter.com/cloudera >> > >> > > > [image: >> > > > > > >> > Cloudera on Facebook] <https://www.facebook.com/cloudera> >> > > [image: >> > > > > > >> > Cloudera on LinkedIn] < >> > > https://www.linkedin.com/company/cloudera> >> > > > > > >> > ------------------------------ >> > > > > > >> > ------------------------------ >> > > > > > >> > >> > > > > > >> >> > > > > > >> >> > > > > > >> -- >> > > > > > >> *István Tóth* | Sr. Staff Software Engineer >> > > > > > >> *Email*: st...@cloudera.com >> > > > > > >> cloudera.com <https://www.cloudera.com> >> > > > > > >> [image: Cloudera] <https://www.cloudera.com/> >> > > > > > >> [image: Cloudera on Twitter] <https://twitter.com/cloudera> >> > > [image: >> > > > > > >> Cloudera on Facebook] <https://www.facebook.com/cloudera> >> > [image: >> > > > > > >> Cloudera >> > > > > > >> on LinkedIn] <https://www.linkedin.com/company/cloudera> >> > > > > > >> ------------------------------ >> > > > > > >> ------------------------------ >> > > > > > >> >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > *István Tóth* | Sr. Staff Software Engineer >> > > > > *Email*: st...@cloudera.com >> > > > > cloudera.com <https://www.cloudera.com> >> > > > > [image: Cloudera] <https://www.cloudera.com/> >> > > > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> >> [image: >> > > > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >> > > > Cloudera >> > > > > on LinkedIn] <https://www.linkedin.com/company/cloudera> >> > > > > ------------------------------ >> > > > > ------------------------------ >> > > > > >> > > > >> > > >> > > >> > > -- >> > > *István Tóth* | Sr. Staff Software Engineer >> > > *Email*: st...@cloudera.com >> > > cloudera.com <https://www.cloudera.com> >> > > [image: Cloudera] <https://www.cloudera.com/> >> > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: >> > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >> > Cloudera >> > > on LinkedIn] <https://www.linkedin.com/company/cloudera> >> > > ------------------------------ >> > > ------------------------------ >> > > >> > >> >> >> -- >> *István Tóth* | Sr. Staff Software Engineer >> *Email*: st...@cloudera.com >> cloudera.com <https://www.cloudera.com> >> [image: Cloudera] <https://www.cloudera.com/> >> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: >> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >> Cloudera >> on LinkedIn] <https://www.linkedin.com/company/cloudera> >> ------------------------------ >> ------------------------------ >> >
