Revision 1 as of 2008-07-23 04:20:15
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 5:||Line 5:|
|Release planning is primarily coordinated through [http://issues.apache.org/jira/browse/ZOOKEEPER ZooKeeper's JIRA database]. Use the "Roadmap" tab to see specific plans for upcoming releases.||Release planning is primarily coordinated through [[http://issues.apache.org/jira/browse/ZOOKEEPER|ZooKeeper's JIRA database]]. Use the "Roadmap" tab to see specific plans for upcoming releases.|
|Line 33:||Line 33:|
|For more details on how releases are created, see [:ZooKeeper/HowToRelease: HowToRelease].||For more details on how releases are created, see [[ZooKeeper/HowToRelease| HowToRelease]].|
This page describes ZooKeeper's release policies.
Release planning is primarily coordinated through ZooKeeper's JIRA database. Use the "Roadmap" tab to see specific plans for upcoming releases.
ZooKeeper release numbers are of the form major.minor.point.
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 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 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, minor releases follow the rules for major releases, except they are still made every few months.
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.