Thank you for your comments. I'll create a vote thread to mark 3.1.x EOL. -Akira
On Tue, May 25, 2021 at 12:46 AM Ayush Saxena <ayush...@gmail.com> wrote: > > +1, to mark 3.1.x EOL. > Apache Hive does depends on 3.1.0 as of now, but due to guave upgrade on > branch-3.1, the attempt to migrate to latest 3.1.x didn’t work for me atleast > couple of months back. So, mostly 3.3.1 would be the only option replacing > 3.1.0 there or at worst 3.3.2 in a couple of months. > > > -Ayush > > > On 24-May-2021, at 8:43 PM, Arpit Agarwal <aagar...@cloudera.com.invalid> > > wrote: > > > > +1 to EOL 3.1.x at least. > > > > > >> On May 23, 2021, at 9:51 PM, Wei-Chiu Chuang > >> <weic...@cloudera.com.INVALID> wrote: > >> > >> Sean, > >> > >> For reasons I don't understand, I never received emails from your new > >> address in the mailing list. Only Akira's response. > >> > >> I was just able to start a thread like this. > >> > >> I am +1 to EOL 3.1.5. > >> Reason? Spark is already on Hadoop 3.2. Hive and Tez are actively working > >> to support Hadoop 3.3. HBase supports Hadoop 3.3 already. They are the most > >> common Hadoop applications so I think a 3.1 isn't that necessarily > >> important. > >> > >> With Hadoop 3.3.1, we have a number of improvements to support a better > >> HDFS upgrade experience, so upgrading from Hadoop 3.1 should be relatively > >> easy. Application upgrade takes some effort though (commons-lang -> > >> commons-lang3 migration for example) > >> I've been maintaining the HDFS code in branch-3.1, so from a > >> HDFS perspective the branch is always in a ready to release state. > >> > >> The Hadoop 3.1 line is more than 3 years old. Maintaining this branch is > >> getting trickier. I am +100 to reduce the number of actively maintained > >> release line. IMO, 2 Hadoop 3 lines + 1 Hadoop 2 line is a good idea. > >> > >> > >> > >> For Hadoop 3.3 line: If no one beats me, I plan to make a 3.3.2 in 2-3 > >> months. And another one in another 2-3 months. > >> The Hadoop 3.3.1 has nearly 700 commits not in 3.3.0. It is very difficult > >> to make/validate a maint release with such a big divergence in the code. > >> > >> > >>> On Mon, May 24, 2021 at 12:06 PM Akira Ajisaka <aajis...@apache.org > >>> <mailto:aajis...@apache.org>> wrote: > >>> > >>> Hi Sean, > >>> > >>> Thank you for starting the discussion. > >>> > >>> I think branch-2.10, branch-3.1, branch-3.2, branch-3.3, and trunk > >>> (3.4.x) are actively maintained. > >>> > >>> The next releases will be: > >>> - 3.4.0 > >>> - 3.3.1 (Thanks, Wei-Chiu!) > >>> - 3.2.3 > >>> - 3.1.5 > >>> - 2.10.2 > >>> > >>>> Are there folks willing to go through being release managers to get more > >>> of these release lines on a steady cadence? > >>> > >>> Now I'm interested in becoming a release manager of 3.1.5. > >>> > >>>> If I were to take up maintenance release for one of them which should it > >>> be? > >>> > >>> 3.2.3 or 2.10.2 seems to be a good choice. > >>> > >>>> Should we declare to our downstream users that some of these lines > >>> aren’t going to get more releases? > >>> > >>> Now I think we don't need to declare that. I believe 3.3.1, 3.2.3, > >>> 3.1.5, and 2.10.2 will be released in the near future. > >>> There are some earlier discussions of 3.1.x EoL, so 3.1.5 may be a > >>> final release of the 3.1.x release line. > >>> > >>>> Is there downstream facing documentation somewhere that I missed for > >>> setting expectations about our release cadence and actively maintained > >>> branches? > >>> > >>> As you commented, the confluence wiki pages for Hadoop releases were > >>> out of date. Updated [1]. > >>> > >>>> Do we have a backlog of work written up that could make the release > >>> process easier for our release managers? > >>> > >>> The release process is documented and maintained: > >>> https://cwiki.apache.org/confluence/display/HADOOP2/HowToRelease > >>> Also, there are some backlogs [1], [2]. > >>> > >>> [1]: > >>> https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+Active+Release+Lines > >>> [2]: https://cwiki.apache.org/confluence/display/HADOOP/Roadmap > >>> > >>> Thanks, > >>> Akira > >>> > >>> On Fri, May 21, 2021 at 7:12 AM Sean Busbey <sbus...@apple.com.invalid> > >>> wrote: > >>>> > >>>> > >>>> Hi folks! > >>>> > >>>> Which release lines do we as a community still consider actively > >>> maintained? > >>>> > >>>> I found an earlier discussion[1] where we had consensus to consider > >>> branches that don’t get maintenance releases on a regular basis > >>> end-of-life > >>> for practical purposes. The result of that discussion was written up in > >>> our > >>> wiki docs in the “EOL Release Branches” page, summarized here > >>>> > >>>>> If no volunteer to do a maintenance release in a short to mid-term > >>> (like 3 months to 1 or 1.5 year). > >>>> > >>>> Looking at release lines that are still on our download page[3]: > >>>> > >>>> * Hadoop 2.10.z - last release 8 months ago > >>>> * Hadoop 3.1.z - last release 9.5 months ago > >>>> * Hadoop 3.2.z - last release 4.5 months ago > >>>> * Hadoop 3.3.z - last release 10 months ago > >>>> > >>>> And then trunk holds 3.4 which hasn’t had a release since the branch-3.3 > >>> fork ~14 months ago. > >>>> > >>>> I can see that Wei-Chiu has been actively working on getting the 3.3.1 > >>> release out[4] (thanks Wei-Chiu!) but I do not see anything similar for > >>> the > >>> other release lines. > >>>> > >>>> We also have pages on the wiki for our project roadmap of release[5], > >>> but it seems out of date since it lists in progress releases that have > >>> happened or branches we have announced as end of life, i.e. 2.8. > >>>> > >>>> We also have a group of pages (sorry, I’m not sure what the confluence > >>> jargon is for this) for “hadoop active release lines”[6] but this list has > >>> 2.8, 2.9, 3.0, 3.1, and 3.3. So several declared end of life lines and no > >>> 2.10 or 3.2 despite those being our release lines with the most recent > >>> releases. > >>>> > >>>> Are there folks willing to go through being release managers to get more > >>> of these release lines on a steady cadence? > >>>> > >>>> If I were to take up maintenance release for one of them which should it > >>> be? > >>>> > >>>> Should we declare to our downstream users that some of these lines > >>> aren’t going to get more releases? > >>>> > >>>> Is there downstream facing documentation somewhere that I missed for > >>> setting expectations about our release cadence and actively maintained > >>> branches? > >>>> > >>>> Do we have a backlog of work written up that could make the release > >>> process easier for our release managers? > >>>> > >>>> > >>>> [1]: https://s.apache.org/7c8jt > >>>> [2]: https://s.apache.org/4no96 > >>>> [3]: https://hadoop.apache.org/releases.html > >>>> [4]: https://s.apache.org/1bvwe > >>>> [5]: https://cwiki.apache.org/confluence/display/HADOOP/Roadmap > >>>> [6]: > >>> https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+Active+Release+Lines > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org > >>>> For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org > >>> <mailto:yarn-dev-unsubscr...@hadoop.apache.org> > >>> For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org > >>> <mailto:yarn-dev-h...@hadoop.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
