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