I am OK with going forward for 2.6.5 release given some people may not be ready for migration to 2.7 and we have done some preparation work already. Thanks Chris for pushing the release work forward!
About future releases of 2.6 (after 2.6.5) or any other legacy releases, I think it worth more discussions. I disagree with what Allen said below - Java 6 support should be a solid reason for branch-2.6 release keep going. 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? Our release effort, although driven by different person, should be consistent logically.
I don't think we have clear rules/polices about EOL of legacy releases before. This is a bit off topic here. Will start a new thread later for more discussion.
From: Chris Trezzo <[EMAIL PROTECTED]>
Sent: Friday, August 12, 2016 12:42 AM
To: Karthik Kambatla
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Release thread] 2.6.5 release activities
Thanks everyone for the discussion! Based on what has been said in this
thread, I will move forward on the preparation efforts (working with
Sangjin and the community) for a 2.6.5 release. If there is a strong
objection to this, please let us know.
I see three initial tasks going forward:
1. Fix the pre-commit build for branch-2.6. I am not entirely sure what is
involved here, but will start looking into it using HADOOP-12800 as a
2. Look through the unresolved issues still targeted to 2.6.5 and
resolve/re-target as necessary. There are currently 17 of them:https://issues.apache.org/jira/issues/?jql=(project%20%
3. Look through the backport candidates in the spreadsheet in more detail
and backport/drop as necessary. There are currently 15 of them:https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3olWpOCo6EBAey1WYC
Finally, I think it would be awesome to continue the release end-of-life
discussion. As we get better and better at release cadence it is going to
be really helpful to have an established EOL policy. It will be less
confusing for contributors and help set clear expectations for end users as
to when they need to start making reasonable migration plans, especially if
they want to stay on a well supported release line. I would be happy to
help with this effort as well. It would be great if we could leverage that
discussion and have EOL information for the 2.6 line when we release 2.6.5.
As always, please let me know if I have missed something.
On Thu, Aug 11, 2016 at 1:03 PM, Karthik Kambatla <[EMAIL PROTECTED]>