Updated Drupal 8 release schedule

Note: some of the information on this page is out of date.  For the latest information about how Drupal releases are managed, see http://drupal.org/core/release-cycle.

In talking to Drupal developers at DrupalCon, it was clear that there are some questions about the Drupal 8 feature freeze and code freeze. Questions like: What can we still work on after feature freeze? When do I start porting my Drupal modules to Drupal 8? When can I start testing Drupal 8? Let's address these questions and more in this blog post.

In addition to that, I am aligning our use of alpha and beta releases more inline with industry standards and changing the date of the code freeze, to leave more room to work on improving coherence. Lastly, I also wanted to document my expectations for contributed module developers/authors -- when they are expected or encouraged to do what.

During development phase (now to December 1)

Here are things we do while we're still in development; we aim to prioritize new features and major API changes.

  • New features and major new APIs.
  • Initial conversions of major new APIs, to ensure additional features are not needed to support them.
  • Refactoring required to unblock additional functionality.

During feature freeze (December 1 to April 1)

The goal of the feature freeze is to improve the implementation of existing features and to improve consistency and coherence of core by removing special cases, and unifying duplicate ways of doing things by converting core to use new APIs, etc.

During this phase we stop adding new subsystems. Refactoring of existing subsystems, smaller API changes and API additions are allowed if they help improve consistency and coherence of the existing functionality or are necessary in order to resolve specific critical tasks and bugs.

For example, the following are still welcome and encouraged during feature freeze:

  • Completing conversions of variable_X() to CMI, and removing the variable system.
  • Optimizing and cleaning up bootstrap by refactoring page caching and session handling to use Symfony components.
  • Better integrating features added before feature freeze (e.g., integrating an existing Layout UI with existing context-aware Blocks, or Views with EntityFieldQuery).

We will start rolling alpha releases during the feature freeze. Contributed project authors who want to help improve the core APIs to better support their projects, can use these alpha releases to begin porting their modules, themes, and distributions. Core developers seek feedback and suggestions from contributed project authors on how to streamline the core APIs.

During code freeze (April 1 to RC1)

The goal of the code freeze is to fix remaining bugs, and prepare for release. Improving coherence of the code base is no longer the goal. Hence, we discourage refactoring, and shift attention from things that are nice to do to things that we must do.

From the code freeze on, we will roll beta releases. Contributed project authors should use the beta releases to port and improve their projects. We encourage contributed authors to start early in the code freeze, as we can still make API changes, if necessary, to work around problems.

Site builders are encouraged to test new installations of Drupal 8 on their development servers.

From code freeze until RC1, we want to do this:

  • Improve the Drupal 7 to Drupal 8 upgrade path
  • Performance optimization
  • Security hardening
  • Minor UI improvements
  • String and documentation improvements
  • Other tasks that didn't get done by code freeze, but that core committers consider necessary; these will likely be marked as ‘critical tasks'.

Release Candidate to Release

We release a first Release Candidate when nearly all critical bugs and tasks are fixed, and a Drupal 7 to Drupal 8 upgrade path is functional. We aim to do this at least two months (around July, 2013) before the scheduled release date (around September, 2013).

We encourage Drupal 7 site owners to test the upgrade path and test contributed modules on their staging sites. We also encourage all contributed project authors to finalize their ports, with the goal of stable releases by Drupal 8.0's release date.

Our guiding principles during this phase of development:

  • We try not to change Strings in order to preserve translator efforts.
  • We try not to change UI in order to preserve documentation efforts.
  • We try to support RC to RC upgrades, in order to help early adopters.
  • We try to avoid breaking APIs except in the case of a critical issue.

Special thanks to Nathaniel Catchpole (catch), Angie Byron (webchick), Alex Bronstein (effulgentsia) and Moshe Weitzman (moshe) for their input. I'll continue to evolve these guidelines so more feedback is always welcome.


chx (not verified):

No, I wasn't holding Dries against gunpoint when he wrote this. Nope. Really, not. :)

EdgarPE (not verified):

Performance is not like a bug, something you can fix. Performance is more like a feature, it's something one have to plan, then polish the implementation.

D8 would slow as hell if performance optimization is in the RC phase.

Gábor Hojtsy (not verified):

As far as I am reading the performance example is before the RC phase, not during. Obviously anything that can latter happen, also happen earlier, it is more that what can happen earlier will not necessarily be possible to do later. So if you have your favorite performance issues, feel free to work on them now.

Roger Nyman (not verified):

A clarifying, concrete and necessary post on the path forward. Thanks!

Carey Hartmann (not verified):

Thank you for this article. I'm sure it will be most helpful to many people.

kingbt (not verified):

Hi Dries,

I like Drupal a lot but there are not many themes for it, the comment administration interface is so hard to use (comment moderation takes a lot of time) and modules for drupal 7 are still buggy. I don't want to compare Drupal with Wordpress but I think that Drupal should take some ideas from Wordpress like the comment administration interface, image upload etc.

Now Drupal is for big companies (or for people with a lot of money to invest in a theme and fixing/porting modules) but I think it should be oriented for individuals (blogs, personal sites etc) and non developers too. Maybe so it will attract a bigger community.

Thank you for your time and hope that Drupal 8 will become easier to use than Wordpress.

jobnomade (not verified):

Hi Kingbt,

I see the same challenge for Drupal. The risk is pretty high when Drupal focus on big projects only. Loosing the connection to individuals is a critical path. You pointed out that the number of themes is important, totally agree! I wish there would be much more options for users to pick from.


Drupal UK (not verified):

I submitted a patch for Drupal 7 to allow multi-language date support. I was too late for D7. I hope I can get enough attention to solve this problem. right now, without editing core files, we can't add support other calendars like Persian.

I was going to post this on Core group, but I don't have access there. I think it is very important to make D8 truly multi-language. without the date element, it's not complete package. all we need is a hook for it.

Advice me how I can get core members to support this cause?

Willy Karam (not verified):

It sure would be awesome to bring together the community and initiative leads in in New York for NYC Camp in late July 2013 for a few days of final sprints and release RC1 ... We could try to bring dries, webchick, catch crell, chx, merlin, heyrocker, john albin, moshe, effulgentsia, agentrickard, xjm and others together for 2+ days of sprints/summits followed by a day of presentations to the NYC enterprise community.