Differences between revisions 61 and 62
Revision 61 as of 2016-03-02 00:28:02
Size: 11947
Editor: AndrewWang
Revision 62 as of 2016-07-21 23:01:52
Size: 12221
Editor: AndrewWang
Deletions are marked like this. Additions are marked like this.
Line 40: Line 40:
=== hadoop-3.0 === === Planned for hadoop-3.0.0 ===
  * Classpath isolation on by default [[https://issues.apache.org/jira/browse/HADOOP-11656|HADOOP-11656]]

=== hadoop-3.0.0-alpha1 ===
Line 43: Line 51:
  * Classpath isolation on by default [[https://issues.apache.org/jira/browse/HADOOP-11656|HADOOP-11656]]
Line 50: Line 57:
  * Intra-datanode balancer [[https://issues.apache.org/jira/browse/HDFS-1312|HDFS-1312]]
Line 51: Line 59:
  * YARN Timeline Service v.2 [[https://issues.apache.org/jira/browse/YARN-2928|YARN-2928]]

Hadoop Roadmap

This page describes Hadoop's release policies.

Release planning is primarily coordinated through Hadoop's JIRA database. Use the "Roadmap" tab to see specific plans for upcoming releases.

For ideas about what you might contribute, please see the ProjectSuggestions and HowToContribute pages.

Release Numbering

Hadoop release numbers are of the form major.minor.point.

Major Releases

Major releases signify incompatible API changes. Upgrading between major releases will generally require changes to user code. We try to facillitate API upgrades by introducing new APIs in the prior major version, deprecating APIs that will be removed.

A major release primarily just removes APIs and features that were deprecated in the prior major release. Thus, to upgrade to a new major release, one should update ones code so that it compiles without deprecation warnings in the final minor release of the prior major cycle.

Across all releases with the same major version, user-applications work without the need for 'any' change. Thus every release with the same major version is both API and 'on the wire' compatible.

Major releases are made as needed, perhaps annually or even further apart.

Minor Releases

Minor releases are made regularly, every few months. Their APIs are back-compatible with prior minor releases, but might include new features, improvements and bug fixes. Also, across minor releases

Across all releases with the same major version, user-applications work without the need for 'any' change. Thus every release with the same major version is both API and 'on the wire' compatible.

Point Releases

Point releases are made to fix blocker bugs from an operational perspective. They do not introduce new features or make other improvements other than fixing bugs. They are made on-demand.

Across all releases with the same major version, user-applications work without the need for 'any' change. Thus every release with the same major version is both API and 'on the wire' compatible.

Note: The above rules do not apply until the 1.0 release. Prior to 1.0, minor releases follow the rules for major releases, except they are still made every few months.

Release Process

For major and minor releases, a branch date is selected for the release. The proposed branch date is set as the release date Jira. The release date in Jira is then updated to the expected date that the release will be available.

On the branch date, a branch is created for the minor release cycle. After this, only patches for issues rated "blocker" are applied to the branch. No new features or other improvements are added to branches. All new features must be added to trunk prior to the branch date.

For more details on how releases are created, see HowToRelease.

Hadoop 3.x Releases

Planned for hadoop-3.0.0

  • HDFS
  • YARN


Hadoop 2.x Releases


    • 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.
    • Classpath isolation for downstream clients HADOOP-11656

  • HDFS
  • YARN
    • Early work for disk and network isolation in YARN: YARN-2139, YARN-2140
    • YARN Timeline Service Next generation: YARN-2928.



  • HDFS
  • YARN


  • HDFS
  • YARN
    • YARN-4233 YARN Timeline Service v1.5

    • YARN-3214 Supporting non-exclusive node-labels: Alpha feature

    • YARN-1963 Support priorities across applications within the same queue: Alpha feature

    • YARN-3611 Support Docker Containers In LinuxContainerExecutor: Alpha feature

    • YARN-1197 Support changing resources of an allocated container: Alpha feature



Released: 2014-11-18


Released: 2014-08-11


  • HDFS
  • YARN
    • Bug fixes

Released: 2014-04-07


  • HDFS
    • Enable support for heterogeneous storages in HDFS (phase 1) HDFS-2832

    • HDFS in-memory caching HDFS-4949

  • YARN
  • Overall
    • Important bug fixes and improvements since hadoop-2.2.

Released: 2014-02-20


Released: 2013-10-13

  • HDFS
    • High Availability for HDFS
    • HDFS Federation
    • HDFS Snapshots
    • NFSv3 access to data in HDFS
  • YARN
    • Stable
    • API Stability
  • Map-Reduce
    • Binary Compatibility for MapReduce applications between Hadoop v1 and Hadoop v2 to ease migration

  • Overall
    • Stable
    • Performance
    • Support for running Hadoop on Microsoft Windows
    • Integration testing for the entire Apache Hadoop ecosystem at the ASF.

Hadoop 1.x - Sustaining Releases

The current sustaining branch is branch-1. It was branched from branch-0.20 with many features including security integrated in.

Because 0.21 had already been released, we added a new level to the release numbering. Thus version numbers on this branch look like 0.20.X.Y where X is > 200 and denotes the minor release from the branch. The Y denotes the point release that is intended for critical bug fixes to a previous sustaining release. The release became the Hadoop 1.0.0 release, and we are now back to a three part (major.minor.point) version scheme. Changes for the next point releases of the sustaining branch need to be merged from branch-1 to branch-1.0 (or branch-1.1 etc). See the Hadoop Releases Page to see the full list of sustaining releases.

The Release Manager for a sustaining release should announce the code freeze date as far in advance as possible, on the general list. Prior to that date, anyone interested in contributing to the release submits a patch to branch-1, and adds the sustaining release number to “Target Version/s” in the Jira. Only functionality already committed to trunk should be submitted to a sustaining release. (The exception is if the functionality is not applicable to trunk.) The Release Manager is fully responsible for release content and timelines.

After the code freeze date, the Release Manager will generate the release candidate and call a release vote in the usual way. After that point, only patches for issues rated “blocker” may be added to the release.

Roadmap (last edited 2016-07-21 23:01:52 by AndrewWang)