Last updated December 5, 2013.

On this page

  1. Drupal 8 release cycle at a glance
  2. Development phase
  3. Feature completion phase
  4. Clean-up phase and alpha releases
  5. API completion phase and beta releases
  6. 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

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.

//drupal.org/node/2076195
(Download as PDF)
| (Text version)

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.)

Alpha releases

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.)

The API freeze date for Drupal 8 was July 1, 2013. From this point, the issue thresholds are reduced weekly. See the API completion phase issue queue thresholds for more information.

Beta releases

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.

Release candidates

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.

Comments