ZooKeeper Roadmap

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.

Release Numbering

ZooKeeper 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, 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 - OUTDATED!.