hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "Roadmap" by Arun C Murthy
Date Fri, 06 Dec 2013 00:04:39 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The "Roadmap" page has been changed by Arun C Murthy:
https://wiki.apache.org/hadoop/Roadmap?action=diff&rev1=21&rev2=22

  
  For more details on how releases are created, see HowToRelease.
  
- == 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 [[http://hadoop.apache.org/common/releases.html|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.
- 
  == Hadoop 2.x Releases ==
  
  === hadoop-2.4 ===
@@ -70, +60 @@

  
  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 [[http://hadoop.apache.org/common/releases.html|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.
+ 

Mime
View raw message