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