hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Trezzo <ctre...@gmail.com>
Subject Re: [Release thread] 2.6.5 release activities
Date Fri, 16 Sep 2016 21:51:02 GMT
We have now cut branch-2.6.5.

On Wed, Sep 14, 2016 at 4:38 PM, Sangjin Lee <sjlee@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 <sjlee@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 <ctrezzo@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 <
>>> aw@effectivemachines.com
>>> > wrote:
>>>
>>> >
>>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jdu@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-unsubscribe@hadoop.apache.org
>>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>> >
>>> >
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message