I think it makes sense to have a 2.8 release since there are a tremendous number of JIRAs in 2.8 that are not in 2.7. Doing a 3.x release seems like something we should consider separately since it would not have the same compatibility guarantees as a 2.8 release. There's a pretty big delta between trunk and 2.8 as well.
cheers, Colin On Sat, Sep 26, 2015 at 1:36 PM, Chris Douglas <cdoug...@apache.org> wrote: > With two active sustaining branches (2.6, 2.7), what would you think > of releasing trunk as 3.x instead of pushing 2.8? There are many new > features (EC, Y1197, etc.), and trunk could be the source of several > alpha/beta releases before we fork the 3.x line. -C > > On Sat, Sep 26, 2015 at 12:49 PM, Vinod Vavilapalli > <vino...@hortonworks.com> wrote: >> As you may have noted, 2.8.0 got completely derailed what with 2.7.x and the >> unusually long 2.6.1 release. >> >> With 2.6.1 out of the way, and two parallel threads in progress for 2.6.2 >> and 2.7.2, it’s time for us to look back at where we are with Hadoop 2.8. >> >> I’ll do a quick survey of where the individual features are and the amount >> of content already present in 2.8 and kick-start 2.8.0 process again. >> >> +Vinod >> >> >>> On Apr 21, 2015, at 2:39 PM, vino...@apache.org wrote: >>> >>> With 2.7.0 out of the way, and with more maintenance releases to stabilize >>> it, I propose we start thinking about 2.8.0. >>> >>> Here's my first cut of the proposal, will update the Roadmap wiki. >>> - Support *both* JDK7 and JDK8 runtimes: HADOOP-11090 >>> - Compatibility tools to catch backwards, forwards compatibility issues at >>> patch submission, release times. Some of it is captured at YARN-3292. This >>> also involves resurrecting jdiff (HADOOP-11776/YARN-3426/MAPREDUCE-6310) >>> and/or investing in new tools. >>> - HADOOP-11656 Classpath isolation for downstream clients >>> - Support for Erasure Codes in HDFS HDFS-7285 >>> - Early work for disk and network isolation in YARN: YARN-2139, YARN-2140 >>> - YARN Timeline Service Next generation: YARN-2928. At least branch-merge >>> + early peek. >>> - Supporting non-exclusive node-labels: YARN-3214 >>> >>> I'm experimenting with more agile 2.7.x releases and would like to continue >>> the same by volunteering as the RM for 2.8.x too. >>> >>> Given the long time we took with 2.7.0, the timeline I am looking at is >>> 8-12 weeks. We can pick as many features as they finish along and make a >>> more predictable releases instead of holding up releases for ever. >>> >>> Thoughts? >>> >>> Thanks >>> +Vinod >>
