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