Hi Shilun, Thanks very much for your great work and bringing up this discussion.
>> Ongoing Support for the Hadoop 3.4 Branch >It’s not just 3.4 — we currently have active release lines for 2.10, >3.2, and 3.3 as well. The officially designated EOL release lines are >listed here [1]. Personally, I think it’s time we consider marking 3.2 >and 3.3 as EOL. However, I would be cautious about doing the same for >3.4 immediately after the 3.5.0 release. The current active release lines are 2.10, 3.3 and 3.4[1]. And IIRC, 2.10.2 will be the last version of release line 2.10. If we consider push 3.3 as EOL, there will be 3.4 only. I agree with Ayush's point, we need to keep line 3.4 even if release line 3.5 will happen. > Preparation for Hadoop 3.5 Release Suggests to support JDK17 first, while running smoothly then considering other stable JDKs. > Operating System Support Strategy Strong +1 from my side. > Release Strategy Under Multi-JDK Builds If the `Release Strategy` is for the next line 3.5, I think it's OK to support JDK17 only, Other active release lines(3.4), I think we should be cautious to cut downs JDK version support. Thanks again. Best Regards, - He Xiaoqiao [1] https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+Active+Release+Lines On Fri, Jul 11, 2025 at 5:58 PM Cheng Pan <pan3...@gmail.com> wrote: > > Hi Shilun, > > Thanks for your efforts on JDK 17 support and for bringing up this discussion. > > Glad to hear that the community considers moving the supported JDK > baseline from 8 to a higher version(maybe 11 or 17, both sound good). > > Also agree to discontinue building support for OS once it reaches EOL, > even in a patched release. > > > Remove unsupported base images from our Dockerfiles or upgrade them > > to newer versions; > > > > Provide documentation to help users build on older systems; > > I have some different ideas for this purpose. I think the Dockerfile itself > is the best documentation for developers to set up a building environment, > for branch-3.4, we can stop testing on OS that is EOL and cause building > failures, but keep the Dockerfile in the repo so that users who want to build > on that OS can refer to it and fix the issues by themselves. > > For now, I think we should > > 1. Remove CentOS 7 testing and Dockerfile on trunk > 2. Remove CentOS 7 testing on branch-3.4 > 3. Migrate CentOS 8 to other supported RHEL like OS 9 or 10 > 4. Upgrade Debian 10 to 12 or 13(coming soon), Ubuntu 20.04 to 24.04 > > Thanks, > Cheng Pan > > On 2025/07/11 05:44:06 slfan1989 wrote: > > Dear community, > > > > I'd like to initiate a discussion on the future release and support > > strategy for Hadoop. This includes a few important topics that I believe we > > should align on: > > 1. Ongoing Support for the Hadoop 3.4 Branch > > > > As it stands, Hadoop 3.4 is the last release line that supports Java 8. It > > is expected that Java 8 compilation support will be officially removed from > > the trunk branch after a community vote. > > At the same time, the trunk branch is increasingly diverging from the 3.4 > > line due to the adoption of JUnit 5 and new features based on JDK17 syntax. > > As a result, future bug fixes and backports will become significantly more > > difficult. > > Given this, I’d like to ask: *after the release of hadoop-3.4.2, does the > > community plan to continue maintaining and releasing hadoop-3.4.3 or other > > 3.4-series versions?* > > 2. Preparation for Hadoop 3.5 Release > > > > With the JDK17 support work nearing completion, it’s time to start planning > > for the Hadoop 3.5 release. Specific questions for discussion include: > > > > > > - > > > > Should we set up a new CI pipeline for JDK17 on the trunk branch? > > - > > > > Should we also add support for JDK21 in CI? > > - > > > > If JDK21 support is added, can we remove the existing JDK11 pipeline? > > > > 3. Operating System Support Strategy > > > > Several major OS distributions—CentOS 7, CentOS 8, and Debian 10—have > > already reached or are approaching end-of-life (EOL). > > Should we adjust our support policy for these systems? For example: > > > > - > > > > Officially deprecate EOL systems; > > - > > > > Provide documentation-only support for compilation; > > - > > > > Remove outdated base images from Dockerfiles. > > > > 4. Release Strategy Under Multi-JDK Builds > > > > As we prepare to support JDK11, JDK17, and JDK21, we also need a clear > > strategy for future releases. Key questions include: > > > > - > > > > Should we publish multiple build variants like: hadoop-3.5.0-jdk11, > > hadoop-3.5.0-jdk17, hadoop-3.5.0-jdk21? > > - > > > > What naming convention should we adopt for these variants? > > - > > > > For Maven Central artifacts, should we distinguish by JDK version or > > consider a unified approach? > > > > Additional Context and Suggestions from My Side: > > > > 1. > > > > The JDK17 compatibility work is being tracked under HADOOP-17177 > > <https://issues.apache.org/jira/browse/HADOOP-17177>. I am in the > > process of reviewing and linking all relevant JIRAs—both completed and > > pending—to this umbrella JIRA, and will share an overview in the coming > > week. > > 2. > > > > Regarding the JUnit 5 migration: > > Based on our experience, JUnit 5 introduces significant differences > > compared to JUnit 4. It fundamentally changes how tests are written and > > run. My proposed upgrade path is as follows: > > - > > > > Complete the migration to *JUnit 5.8.2* (we are still working on HDFS > > and Hadoop-Azure and aim to finish in the next two weeks); > > - > > > > Remove JUnit 4 usage module by module (e.g., Yarn, MapReduce, HDFS, > > Common, etc.); > > - > > > > Upgrade to *JUnit 5.13.2* (as Steve suggested); > > - > > > > Upgrade the *Maven Surefire Plugin*. Earlier issues were due to the > > mixed use of JUnit 4 and 5, which will no longer be a concern > > once JUnit 5 > > is fully adopted; > > - > > > > Upgrade the *Maven version* to 3.9.0 for better compatibility and > > plugin support. > > 3. > > > > Once the JUnit 5 migration is complete, we will conduct a thorough test > > audit to ensure everything runs correctly and mark unstable tests for > > future attention. > > 4. > > > > Regarding legacy OS support, I recommend a "lightweight" approach: > > - > > > > Remove unsupported base images from our Dockerfiles or upgrade them > > to newer versions; > > - > > > > Provide documentation to help users build on older systems; > > - > > > > But *formally discontinue* full support for EOL systems. > > > > I’d appreciate hearing your thoughts on these topics. Looking forward to a > > fruitful discussion! > > > > Best regards, > > Shilun Fan. > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
