We have now cut branch-2.6.5. On Wed, Sep 14, 2016 at 4:38 PM, Sangjin Lee <sj...@apache.org> wrote:
> We ported 16 issues to branch-2.6. We will go ahead and start the release > process, including cutting the release branch. If you have any critical > change that should be made part of 2.6.5, please reach out to us and commit > the changes. Thanks! > > Sangjin > > On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote: > >> Thanks Chris! >> >> I'll help Chris to get those JIRAs marked in his spreadsheet committed. >> We'll cut the release branch shortly after that. If you have any critical >> change that should be made part of 2.6.5 (CVE patches included), please >> reach out to us and commit the changes. If all things go well, we'd like to >> cut the branch in a few days. >> >> Thanks, >> Sangjin >> >> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ctre...@gmail.com> wrote: >> >>> Hi all, >>> >>> I wanted to give an update on the Hadoop 2.6.5 release efforts. >>> >>> Here is what has been done so far: >>> >>> 1. I have gone through all of the potential backports and recorded the >>> commit hashes for each of them from the branch that seems the most >>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash >>> from the backport). >>> >>> 2. I verified if the cherry pick for each commit is clean. This was best >>> effort as some of the patches are in parts of the code that I am less >>> familiar with. This is recorded in the public spread sheet here: >>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol >>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing >>> >>> I am going to need help from committers to get these backports committed. >>> If there are any committers that have some spare cycles, especially if >>> you >>> were involved with the initial commit for one of these issues, please >>> look >>> at the spreadsheet and volunteer to backport one of the issues. >>> >>> As always, please let me know if you have any questions or feel that I >>> have >>> missed something. >>> >>> Thank you! >>> Chris Trezzo >>> >>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer < >>> a...@effectivemachines.com >>> > wrote: >>> >>> > >>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <j...@hortonworks.com> wrote: >>> > > >>> > > In this community, we are so aggressive to drop Java 7 support in >>> 3.0.x >>> > release. Here, why we are so conservative to keep releasing new bits to >>> > support Java 6? >>> > >>> > I don't view a group of people putting bug fixes into a micro >>> > release as particularly conservative. If a group within the community >>> > wasn't interested in doing it, 2.6.5 wouldn't be happening. >>> > >>> > But let's put the releases into context, because I think it >>> tells >>> > a more interesting story. >>> > >>> > * hadoop 2.6.x = EOLed JREs (6,7) >>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8) >>> > * hadoop 3.x = JRE 8 >>> > * hadoop 4.x = JRE 9 >>> > >>> > There are groups of people still using JDK6 and they want bug >>> > fixes in a maintenance release. Boom, there's 2.6.x. >>> > >>> > Hadoop 3.x has been pushed off for years for "reasons". So we >>> > still have releases coming off of branch-2. If 2.7 had been released >>> as >>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this >>> > weird wart in the middle of that supports JDK7 and JDK8. Given the >>> public >>> > policy and roadmaps of at least one major vendor at the time of this >>> > writing, we should expect to see JDK7 support for at least the next two >>> > years after 3.x appears. Bang, there's 2.x, where x is some large >>> number. >>> > >>> > Then there is the future. People using JRE 8 want to use newer >>> > dependencies. A reasonable request. Some of these dependency updates >>> won't >>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of >>> compatible >>> > way without breaking the universe. (Tons of JIRAs on this point.) This >>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines). >>> > Kapow, there's 3.x >>> > >>> > The log4j community has stated that v1 won't work with JDK9. In >>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading >>> to >>> > v2 will break the log4j properties file (and maybe other things?). >>> Another >>> > incompatible change and it likely won't appear until Apache Hadoop v4 >>> > unless someone takes the initiative to fix it before v3 hits store >>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4. >>> > >>> > Having major release cadences tied to JRE updates isn't >>> > necessarily a bad thing and definitely forces the community to a) >>> actually >>> > stop beating around the bush on majors and b) actually makes it >>> relatively >>> > easy to determine what the schedule looks like to some degree. >>> > >>> > >>> > >>> > >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org >>> > For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org >>> > >>> > >>> >> >> >
