Drupal core release cycle

Last updated May 16, 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. Polish phase and beta releases
6. Release candidates
7. Frequently asked questions

Drupal 8 release cycle at a glance

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.

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 code freeze deadline, so long as they do not significantly increase the overall technical debt. (API changes that require extensive follow-up issues are very rarely accepted 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.
• No upgrade path is provided between alpha releases.
• Production sites should not use alphas, because of the risk of data loss.
• No upgrade path is supported from alpha releases to any later release.

Polish phase and beta releases

The polish phase begins after the code freeze deadline. During this phase, backwards compatibility-breaking API changes are only allowed when they are needed to fix major and critical bugs and tasks. The purpose of the polish phase is to resolve critical, release-blocking issues and to provide contributed module developers with a stable API to port their modules.

(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 code freeze date for Drupal 8 is July 1, 2013. Afterward, the issue thresholds will be reduced weekly. See the polish phase issue queue thresholds for more information.

Beta releases

We begin publishing beta releases during the polish phase, once there are no known critical bugs in the upgrade path from the latest released version of Drupal.

• Beta releases have a relatively stable API, and we recommend that all module developers begin porting their modules once a beta release is available.
• A working upgrade path is provided from the previous Drupal version to beta releases. (We encourage testing the upgrade path at this point. However, back up the original database and be prepared to repeat the process with the next beta release.)
• An upgrade path is 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, including critical bugs in the previous version's upgrade path. (So, for example, we need to resolve any known critical issues in the Drupal 6 to Drupal 7 upgrade path before creating a release candidate for Drupal 8.) Maintainers will also evaluate the major bugs and tasks before creating the first release candidate.

• A stable upgrade path is provided between release candidates and from the previous version of Drupal.
• 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.
• User interfaces and translatable strings will no longer change after the first release candidate.

A release candidate becomes a release if no critical issues are discovered with it during a testing period of at least two weeks.

Frequently asked questions

What's an API change?

As a general rule, an API change means anything that would cause a module or theme developer, or someone writing documentation about the next version of Drupal, to have to redo work. Changing function or hook signatures, adding/removing API functions and hooks, adding/removing/changing theme functions, adding/removing/changing template files or template variables, and so on.

Once we hit code freeze, we only allow API changes if they go towards fixing critical bugs. If there's a way to fix a "major" or "normal" bug without changing the API, we go with that, same as we do in stable releases.

What's a critical bug?

A critical bug is something that breaks Drupal so horribly in a way that affects so many users that we can't possibly release without it being fixed. Priority levels of issues has a good breakdown of the differences in priority levels.

As a general rule, these include:

• Upgrade path-related bugs
• Bugs that cause data loss
• Bugs that create security vulnerabilities
• Serious regressions from behaviour that worked in previous releases
• Bugs that cause testbot to fail

The ultimate call on what is critical or not is with the core maintainers.

There is, however, a much longer list of things that are not critical bugs, including:

• Awful problems that also existed in previous releases. If they were not bad enough to block the release of the previous version of Drupal, they will not block the next release, either.
• Edge cases that, while pretty terrible, affect a small minority of users and those users have some kind of reasonable way to work around the problem.
• Developer Experience (DX) problems that do not prevent Drupal from being used.
• User Experience (UX) problems that do not prevent Drupal from being used.
• Themer Experience (TX) problems that do not prevent Drupal from being used.

What's the harm in letting in API changes late?

There are consequences every time we deviate from the overall release plan:

• Takes time and focus away from critical, release-blocking issues: Since none of us are being paid to work on Drupal core, we need to allocate our attention and focus in the most efficient way. That generally means focusing on critical, release-blocking bugs first, everything else second.
• Sends a signal to all other core contributors that we're still in "polish" phase: All of us have our own pet niggles with Drupal that we really wish were better than they are. Tweaking a theme function here. Adding a hook there. If the core maintainers send up the signal that these sorts of patches are still on the table, suddenly everyone wants to jump in and add their own pet project, too. Which means critical issues aren't being looked at, and core maintainers need to divide their attention.
• Creates morale issues and dissent: The flip side of the above. When people perceive favouritism or special treatment (contributor X's "polish phase" patches are getting committed during release phase while contributor Y's were bumped to Drupal 8), it builds resentment and mistrust. It also builds this feeling when the vast majority of the team is working hard on the "core" issues leading directly to release, but there are other people off in the sidelines scratching their own itches.
• Makes the release cycle even longer: Each one of these patches are not something that happens for free. Each patch that goes into core needs to be read, evaluated, reviewed, tested, tweaked, tested again, given final look-over by a core maintainer, and finally committed. This is all time not being spent on the "core" issues that get the release out the door.

  Additionally, every time code changes, it opens up the possibility for follow-up issues, or at the very least re-rolls in other patches to fix tests or whatnot.

• Eliminates incentive to join with community at appropriate times: If we don't ever end code thaw, and we don't ever end polish phase, what on earth is the incentive for helping out during those times when we as a community really need people to rally?

  If we are changing APIs and the theme system months after we declared an API/markup freeze, what's the incentive for porting modules and themes during code freeze? Much safer to wait until the next version actually ships, which inevitably leads to a major core release with 0 contributed module support, which isn't good for anyone.

Will one little patch like this end the world? No, of course not. But it's death by a thousand cuts. So core maintainers and major core contributors tend to give more and more pushback the later in the cycle major changes are introduced.

What about normal and minor priority bug fixes?

No thresholds have been added for normal and minor priority issues, however the 'mini code slushes' will allow normal and minor bug fixes to be committed while working towards getting the major/critical queues below threshold.

What about Drupal 6?

Issue thresholds do not apply to Drupal 6. There are significant changes between Drupal 6 and Drupal 7, and Drupal 6 does not have many automated tests. This makes the process of backporting even bug fixes more involved than from Drupal 8 to Drupal 7.

Can I add new major or critical issues when the counts are over the threshold?

Yes! These are thresholds rather than limits - and only affect which patches will be committed, not what can be reported or worked on during code slushes. One thing to bear in mind is that having the thresholds is likely to lead to closer triage of the core issue queue, and more of a distinction made between bugs, tasks and feature requests. You may find your issue is triaged to a different priority or category. Issues can be better triaged if there is a clear explanation of the problem (including steps to reproduce) and/or a clear explanation of the proposed solution.