hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lucene-hadoop Wiki] Update of "Roadmap" by DougCutting
Date Wed, 22 Aug 2007 17:57:23 GMT
Dear Wiki user,

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

The following page has been changed by DougCutting:
http://wiki.apache.org/lucene-hadoop/Roadmap

The comment on the change is:
describe release numbering

------------------------------------------------------------------------------
  = Hadoop Roadmap =
  
- This page describes release plans for Hadoop.
+ This page describes Hadoop's release strategy.
  
- Release planning is primarily coordinated through [http://issues.apache.org/jira/browse/HADOOP
Hadoop's JIRA database].  Use the "Roadmap" tab to see plans for upcoming releases.
+ Release planning is primarily coordinated through [http://issues.apache.org/jira/browse/HADOOP
Hadoop's JIRA database].  Use the "Roadmap" tab to see specific plans for upcoming releases.
  
- In general, we aim for a release every other month.  A release is branched in [http://lucene.apache.org/hadoop/version_control.html
subversion] on the first Friday of release months.  After this, only patches for issues rated
"blocker" are applied to the branch.  In particular, no new features are added release branches.
 All new features must be added to trunk prior to the branch date.
+ == 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 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.
+ 
+ Major releases are made as needed, perhaps annually.
+ 
+ === 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.
+ 
+ === Point Releases ===
+ 
+ Point releases are made to fix critical bugs.  They do not introduce new features or make
other improvements other than fixing bugs.  They are made on-demand.
+ 
+ ''Note: The above rules do not apply until the 1.0 release.  Prior to 1.0, point 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.
+ 

Mime
View raw message