Drupal 8 development cycle prior to 8.0.0

This page is about the Drupal 8 development cycle leading up to the release of Drupal 8.0.0. For information on the release cycle after 8.0.0, see the Drupal core release cycle overview.

On this page

1. Drupal 8 development 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
7. 8.0.0 and semantic versioning

Drupal 8 development cycle at a glance

See the Drupal core release cycle overview for key upcoming dates and milestones.

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.

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 began 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 began 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 issues. (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.

Beta releases

We began 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 Drupal 8 beta was released on October 1, 2014.

Release candidates

The first release candidate for a new version of Drupal is created once the number of critical bugs issues 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 before the first release candidate and throughout the release candidate phase. To allow for a regular release candidate schedule with incremental improvements in each, 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.

(Download as PDF) | (Google drawing)

• 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 sync 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. See the policy on Allowed changes during the Drupal 8 release for more details.
• 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.

The first Drupal 8 release candidate was released on October 7, 2015.

8.0.0 and semantic versioning

The release date for Drupal 8.0.0 was Thursday, November 19, 2015. This date was chosen based on these criteria: when the rate and nature of incoming critical issues had slowed to ensure a stable, timely release, we chose a release date that could be announced at least three weeks ahead of time, and set on one of the existing core release windows (on the first or third Wednesday of the month). Note that we November 19 was actually the day after the Drupal 7 release window (Thursday rather than Wednesday), with a small buffer to coordinate any followup.

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. See the Drupal core release cycle overview for details.