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.6

hadoop-2.5

Currently, we are targeting this for August, 2014.

hadoop-2.4

Released: 2014-04-07

hadoop-2.3

Released: 2014-02-20

hadoop-2.2

Released: 2013-10-13

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 2014-09-25 02:27:28 by VinodKumarVavilapalli)