Last updated April 2, 2015.
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
- 8.0.0 and semantic versioning
- 8.1.x and minor versions
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||October 1, 2014|
|Beta phase||October 1, 2014||TBD|
|8.1.x development opens||TBD||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.)
The API freeze date for Drupal 8 was July 1, 2013.
We begin publishing beta releases during the API completion phase, once the core data model is complete and critical APIs are stable. A final alpha release is published when there are no more "beta blocker issues" (critical issues that must change the data model or critical APIs). If no additional beta-blocking issues are created within two weeks, then the first beta release is created.
- 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 not guaranteed between beta releases. See the beta-to-beta upgrade path and data model stability policy for more information.
- All core changes during this phase need to be evaluated in terms of the policy for Allowed changes during the beta phase.
- 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.
Drupal 8 (like any software) will continue to have critical bugs found during the release candidate phase and after release. What is important for site owners is that the 8.0.0 release is stable enough that occasional new critical bugs can be resolved quickly, instead of adding to an extensive backlog of (as-yet undiscovered) issues that will cumulatively take many weeks to resolve. For core contributors, it is important that 8.0.0 marks the point at which issues which have been deferred to 8.0.1 can be worked on again, since this may include several hundred major bugs that could seriously affect sites in production.
To this end, the branch maintainers will monitor the rate and nature of incoming critical bugs weekly during the release candidate phase (beginning before the first release candidate). To allow for a regular release schedule with incremental improvements from the previous release, we may tag release candidates with open critical issues. We will schedule an official release date for 8.0.0 a minimum of three weeks in the future when we are confident that the rate of incoming bugs has slowed enough to ensure a stable, timely release.
- Release windows for Drupal core are on the first and third Wednesdays of each month. For stable releases, the first Wednesday is a bugfix release window and the third Wednesday is a security release window.
- Once we reach zero critical issues, the first release candidate is tagged on the next of these release windows (whether bugfix or security) to synch up the Drupal 8 release schedule with that of Drupal 6 and 7. (If the next release window is less than 72 hours away, the following one will be used instead.)
- Further release candidates will be tagged on a fortnightly schedule during each release window.
- If a release candidate goes out with a known critical issue, this will be documented prominently in the release notes.
- During the release candidate phase, only critical issues (as well as documentation improvements, or major issues with very low chance of disruption/regression, on a case-by-case basis) will be committed. Everything else will be deferred to 8.0.1 or later.
- 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.
8.0.0 and semantic versioning
When the rate and nature of incoming critical issues has slowed to ensure a stable, timely release, we will schedule a release date for 8.0.0. The release date will be announced at least three weeks ahead of time, and will be set on one of the existing core release windows (on the first or third Wednesday of the month).
Once the 8.0.0 release date is set, if there are not unexpected critical issues open, we'll allow code-style cleanups to be committed again so long as these have low chance of introducing regressions.
Following Drupal 8.0.0, Drupal will follow semantic versioning with a regular release schedule. Patch-level releases will follow a monthly schedule corresponding to Drupal 7's release windows. Minor releases will follow a six-month schedule.
For more information see:
8.1.x development and minor releases
Specifics for the management of 8.1.x development are under diccussion in.