Seems fine. A contributor should say if they want a patch to go back to branch-2, so we can advise them on compatibility concerns, and tell them to open the backport PRs if they want it to happen. In any case as long as precommit CI jobs for branch-2 compile the source with source level 8 (and they will) we will catch any syntax or API issues and the contributor can either fix them or we can just close the backport PR.
Master and branch-3 branches are expected to diverge from branch-2. Backports will be driven by contributors and if a contributor wants to land something in branch-2 then they must take on any divergence related issues when preparing the backport PRs. This was our practice for branch-1 and was acceptable. Should branch-2 become too difficult to maintain some day we can decide to EOL it when faced with the problem. > > On May 7, 2024, at 9:21 AM, 张铎 <palomino...@gmail.com> wrote: > > The problem is that, if we only compile and run tests on JDK11+, the > contributors may implicitly use some JDK11+ only features and > introduce difference when backporting to branch-2.x. > > Maybe a possible policy is that, once a patch should go into > branch-2.x too, before mering the master PR, we should make sure the > contributor open a PR for branch-2.x too, so we can catch the > differences between the 2 PRs, and whether to align them. > > WDYT? > > Thanks. > > Andrew Purtell <apurt...@apache.org> 于2024年5月7日周二 20:20写道： >> >> I don’t expect 2.x to wind down for up to several more years. We will be >> still using it in production at my employer for a long time and I would >> continue my role as RM for 2.x as needed. HBase 3 is great but not GA yet >> and then some users will want to wait one to a couple years before adopting >> the new major version, especially if migration is not seamless. (We even >> faced breaking changes in a minor upgrade from 2.4 to 2.5 that brought down >> a cluster during a rolling upgrade, so there should be no expectation of a >> seamless upgrade.) My plan is to continue releasing 2.x until, like with >> 1.x, the commits to branch-2 essentially stop, or until the PMC stops >> allowing release of the candidates. >> >> Perhaps we do not need to do a total ban on use of 11 features. We should >> allow a case by case discussion. We can minimize their scope and even >> potentially offer multiversion support like we do with Unsafe access >> utility classes in hbase-thirdparty. There are no planned uses of new 11+ >> APIs and features now anyhow. >> >> >>> On Tue, May 7, 2024 at 7:40 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: >>> >>> For me I think Istvan's plan is also acceptable. >>> >>> So in conclusion, we should >>> >>> 1. Jump to JDK11/JDK17(we could start a new thread to discuss this, >>> maybe also on the user mailing list) >>> 2. Claim and also make sure 3.x does not work with JDK8 >>> 3. Introduce a policy to only allow JDK8 features on master and >>> branch-3.x for a while(maybe still keep the release version as 8?) >>> >>> Any other suggestions? >>> >>> Thanks. >>> >>> Istvan Toth <st...@cloudera.com.invalid> 于2024年4月30日周二 12:45写道： >>>> >>>> Spring is a good argument for JDK17. >>>> >>>> Duo's suggestion is a great step forward, firmly stating that JDK8 is not >>>> officially supported solves most of our expected future CVE problems. >>>> >>>> However, I think that ripping off the bandaid, and making sure that >>> HBase 3 >>>> does not work with Java 8 would be better. >>>> It's easier to accept such a change in a major version than in a minor >>>> version. >>>> >>>> IMO users that are so conservative that they are still using Java 8 are >>>> unlikely to be first movers to a new major release anyway. >>>> >>>> I think that the following upgrade path would optimal: >>>> >>>> - User stays on (supported) Hbase 2.x until ready to upgrade Java >>>> - User upgrades to Java 11/17 with the same HBase >>>> - User upgrades to Hbase 3.x >>>> >>>> As noted, we will need to support 2.x for some time anyway (just like 1.x >>>> was supported for a long time). >>>> >>>> As for the backporting issues: >>>> We could make it a policy to avoid using Java 11+ features in Hbase code >>>> until 2.x supports winds down. >>>> This has worked quite well for Phoenix with Java 7 / Java 8. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Apr 30, 2024 at 3:59 AM 张铎(Duo Zhang) <palomino...@gmail.com> >>> wrote: >>>> >>>>> AFAIK spring 6 and spring-boot 3 have jumped to java17 directly, so if >>> we >>>>> want to upgrade, I also suggest that we jump to java 17 directly. >>>>> >>>>> While upgrading to java 17 can reduce our compatibility work on >>> branch-3+, >>>>> but consider the widely usage for java 8, I think we still need to >>> support >>>>> branch-2 for several years, then this will increase the compatibility >>> work >>>>> as the code between branch-3+ and branch-2.x will be more and more >>>>> different. >>>>> >>>>> So for me, a workable solution is >>>>> >>>>> 1. We first claim that branch-3+ will move minimum java support to 11 >>> or >>>>> 17. >>>>> 2. Start to move the compilation to java 11 or 17, but still keep >>> release >>>>> version 8, and still keep the pre commit pipeline to run java 8, 11, >>> 17, to >>>>> minimum our compatibility work before we have the first 3.0.0 release. >>>>> 3. Cut branch-3.0 and release 3.0.0, so we have a 3.0.0 release, >>> actually >>>>> which can still run on java 8, so it will be easier for our users to >>>>> upgrade to 3.x and reduce our pressure on maintaining branch-2, >>> especially >>>>> do not need to back port new features there. >>>>> 4. Start to move the release version to 11 or 17 on branch-3+, and >>> prepare >>>>> for 3.1.0 release, which will be the real 11 or 17 only release. >>>>> >>>>> Thanks. >>>>> >>>>> Bryan Beaudreault <bbeaudrea...@apache.org>于2024年4月30日 周二02:54写道： >>>>> >>>>>> I am a huge +1 for dropping java8. >>>>>> >>>>>> One reason I would suggest going to 17 is that it seems so hard to >>> change >>>>>> these things given our long development cycle on major releases. >>> There >>>>> are >>>>>> some nice language features in 17, but more importantly is that the >>>>> initial >>>>>> release of java11 was released 6 years ago and java17 released 3 >>> years. >>>>>> Java21 is already released as well. So I could see java17 being >>> widely >>>>>> available enough that we could jump "in the middle" rather than to >>> the >>>>>> oldest LTS. >>>>>> >>>>>> I will say that we're already running java 21 on all of our >>> hbase/hadoop >>>>> in >>>>>> prod (70 clusters, 7k regionservers). I know not every organization >>> can >>>>> be >>>>>> that aggressive, and I wouldn't suggest jumping to 21 in the >>> codebase. >>>>> Just >>>>>> pointing it out in terms of basic support already existing and being >>>>>> stable. >>>>>> >>>>>> On Mon, Apr 29, 2024 at 2:33 PM Andrew Purtell < >>> andrew.purt...@gmail.com >>>>>> >>>>>> wrote: >>>>>> >>>>>>> I also agree that mitigation of security problems in dependencies >>> will >>>>> be >>>>>>> increasingly difficult, as we cannot expect our dependencies to >>>>> continue >>>>>> to >>>>>>> support Java 8. They might, but as time goes on it is less likely. >>>>>>> >>>>>>> A minimum of Java 11 makes a lot of sense. This is where the >>> center of >>>>>>> gravity of the Java ecosystem is, probably. >>>>>>> >>>>>>> A minimum of 17 is aggressive and I don’t see the point unless >>> there >>>>> is a >>>>>>> feature in 17 that we would like to base an improvement on. >>>>>>> >>>>>>>> On Apr 29, 2024, at 1:23 PM, chrajeshbab...@gmail.com wrote: >>>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> With 3.0 on the horizon, we could look into bumping the minimum >>>>>> required >>>>>>>> Java version for HBase. >>>>>>>> >>>>>>>> The last discussion I could find was four years ago, when >>> dropping >>>>> 8.0 >>>>>>>> support was rejected. >>>>>>>> >>>>>>>> https://lists.apache.org/thread/ph8xry0x37cvjj89fp2jk1k48yb7gs46 >>>>>>>> >>>>>>>> Now it's four years later, and the end of OpenJDK support for >>> Java 8 >>>>>> and >>>>>>> 11 >>>>>>>> are much closer. >>>>>>>> (Oracle public support is so short that I consider that >>> irrelevant) >>>>>>>> >>>>>>>> Some critical dependencies (like Jetty) have ended even regular >>>>>> security >>>>>>>> support for Java 8. >>>>>>>> >>>>>>>> By supporting Java 8 we are alse limiting ourselves to using an >>>>> already >>>>>>> 10 >>>>>>>> year old Java release, ignoring any developments in the language. >>>>>>>> >>>>>>>> My take is that with the current dogmatic emphasis on CVE >>> mitigation >>>>>> the >>>>>>>> benefits of bumping the required JDK version outweigh the >>> benefits >>>>> even >>>>>>> for >>>>>>>> the legacy install base, especially it's getting harder and >>> harder to >>>>>> be >>>>>>>> CVE free with Java 8. >>>>>>>> >>>>>>>> Furthermore, with RedHat dropping JDK11 support this year, I >>> think we >>>>>>> could >>>>>>>> also consider bumping the minimum requirement straight to JDK 17. >>>>>>>> >>>>>>>> Hadoop is still on Java 8, but previously it has dropped Java 7 >>>>> support >>>>>>> in >>>>>>>> a patch release, and I wouldn't be surprised if it dropped Java >>> 8 in >>>>> a >>>>>>>> similar manner, so I would not put too much stock in that. >>>>>>>> >>>>>>>> What do you think ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Rajeshbabu. >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> *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> >>>> ------------------------------ >>>> ------------------------------ >>>
