Last updated December 5, 2013.
On this page
- Drupal 8 release cycle at a glance
- Development phase
- Feature completion phase
- Clean-up phase and alpha releases
- API completion phase and beta releases
- Release candidates
Drupal 8 release cycle at a glance
|Phase||Start date||End date|
|Development phase||March 10, 2011||December 1, 2012|
|Feature completion phase||December 1, 2012||February 18, 2013|
|Clean-up phase||February 18, 2013||July 1, 2013|
|API completion phase||July 1, 2013||TBD|
Note that these dates are subject to changes at core maintainers' discretion.
Development phase begins when a new branch of Drupal is opened for development, shortly after the release of the newest Drupal version. During the development phase, any new features or changes can be considered for acceptance, so long as core's technical debt is within the issue thresholds. Absolutely anything goes. Fix inconsistencies that have always annoyed you, re-write the entire Form API, add modules to core, remove modules from core, change APIs, add or remove template files--whatever you can dream up. The drop is always moving.
Drupal 8's development phase ended on December 1, 2012.
After the development phase ends, we gradually reduce the scope of the patches that we accept. The goal is to move the new version of Drupal toward a releasable state while it is under development, and so we increasingly avoid changes that introduce technical debt or other risks to a timely release.
Feature completion phase
The feature completion phase extends between two feature freeze deadlines: an initial feature freeze deadline, and a feature completion deadline.
After the initial feature freeze deadline, major features and refactorings that are already under development may be accepted. Major features or refactorings that were not already under development must be postponed until the next major Drupal version. (Minor new features may still be accepted, at the maintainer's discretion, so long as issue counts are under thresholds.) API changes are still allowed during the feature completion phase.
Drupal 8's feature completion phase lasted from December 1, 2012 to February 18, 2013.
Clean-up phase and alpha releases
After the feature completion deadline, a clean-up phase begins.
API changes are still allowed during the clean-up phase until the API freeze deadline, so long as they do not significantly increase the overall technical debt. (API changes that require extensive follow-up issues are strongly discouraged during this phase, as the goal is not to add more risk to the release timeline.)
We will begin publishing alpha releases during the clean-up phase.
- Alpha releases should be considered unstable and unreliable. They are intended for testing and contributed module development only.
- Contributed module developers should be aware that the API of alpha releases will still change. The point of alpha releases is to allow module developers to identify API deficiencies while they can still be corrected.
- Upgrading from the previous stable version of Drupal to an alpha release is not reliable.
- No upgrade path is provided between alpha releases or to any later release.
- Production sites should not use alphas, because of the risk of data loss.
API completion phase and beta releases
The API completion phase begins after the API freeze deadline. The primary purpose of this phase is to resolve release-blocking issues, and backwards compatibility-breaking API changes are only allowed when they are needed to fix major and critical bugs and tasks. (For more information, see When is an API change needed during the API completion phase?)
(Minor new features may still be accepted, at the maintainer's discretion, so long as they do not introduce API changes and issue counts are under the reduced issue thresholds.)
We begin publishing beta releases during the API completion phase, once the core data model is complete and critical APIs are stable.
- Contributed module and theme developers are encouraged to start porting their modules during this phase to uncover critical API issues while they can still be corrected, but should also be aware that APIs will still change as critical issues are addressed. Developers who wish to go through the upgrade process only once should wait for the first release candidate.
- A data migration path is generally not provided between beta releases.
- Production sites should generally not use betas, because of critical bugs and the risk of data loss.
- Developers may choose to build test sites with beta releases in order to test the new features and APIs.
- User interfaces and translatable strings may still change between beta releases.
The first release candidate for a new version of Drupal is created once the number of critical bugs and tasks is reduced to zero. Maintainers will also evaluate the major bugs and tasks before creating the first release candidate.
- APIs, User interfaces, and translatable strings will generally not change once the first release candidate is created.
- Some developers and early adopters may consider using release candidates in production, but should be aware that there is a chance critical issues could still be uncovered.
A release candidate becomes a release if no critical issues are discovered with it during a testing period of at least two weeks.