Differences between revisions 24 and 25
Revision 24 as of 2013-12-06 21:49:32
Size: 5840
Comment:
Revision 25 as of 2014-01-07 06:27:06
Size: 6063
Editor: JunpingDu
Comment:
Deletions are marked like this. Additions are marked like this.
Line 53: Line 53:
  * Enable support for heterogeneous storages in HDFS (phase 1) [[https://issues.apache.org/jira/browse/HDFS-2832|HDFS-2832]]
Line 56: Line 57:
  * Dynamic Resource Configuration [[https://issues.apache.org/jira/browse/YARN-291|YARN-291]]

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 2.x Releases

hadoop-2.4

Hadoop 2.4 is a release with several substantial features, such as:

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

  • YARN
    • Application History Server YARN-321

    • Enable external systems/frameworks to share resources with Hadoop leveraging Yarn resource scheduling (unmanged containers) YARN-1404

    • Dynamic Resource Configuration YARN-291

    • Resource Manager HA YARN-149

  • MAPREDUCE

Currently, we are targeting this for January, 2014.

hadoop-2.3

Hadoop 2.3 is essentially a bug-fix release and is targetted for 2nd week of December, 2013.

hadoop-2.2

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 0.205.0.1 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 2015-04-22 21:02:19 by VinodKumarVavilapalli)