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 EliCollins: http://wiki.apache.org/hadoop/Roadmap?action=diff&rev1=16&rev2=17 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). + 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. - - See the [[http://hadoop.apache.org/common/releases.html|Hadoop Releases Page]] to see the full list of sustaining releases. Changes 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.
