Note: some of the information on this page is out of date.  For the latest information about how Drupal releases are managed, see

Since Drupal 8 opened for development in March of 2011, the Drupal core team has been hard at work, marching towards a feature freeze of December 1, 2012, just a few short days away!

In that time, we've managed to commit a number of compelling features to Drupal 8: revamped core internals based on the Symfony framework, a new configuration management system, HTML5 form elements and responsive markup, a mobile-friendly administrative toolbar, built-in support for translation, a Twig-based templating system, the Views module, and countless under-the-hood improvements.

The momentum within the Drupal core queue right now is truly staggering, as embodied by this graph:

Drupal core monthly patch volume
Momentum around Drupal core has increased from around 400 patch contributions per month in March of 2011 to over 4,000 in October of 2012.

There are still incredible features for Drupal 8 that are heavily in progress, but not quite there yet, including blocks and layouts, WYSIWYG and inline editing, several more "contributed module to core" projects such as Date, Pathauto, Profile2, and Entity Reference, native web services support, improvements to the entity and field systems, and much. I'm truly impressed by all of the great efforts I see happening in the queue right now.

Given these factors, I have decided -- along with my Drupal 8 co-maintainers Nathaniel Catchpole and Angela Byron -- to introduce a new phase into the Drupal core development cycle: "Feature Completion Phase", from December 1, 2012 until February 18, 2013 (to hit DrupalCon Sydney).

The purpose of this phase will be to provide dedicated time to tie up loose ends on any features that have either been committed already, or features still in the queue that have demonstrated substantial progress before December 1, but are not quite "there" yet. While hard-and-fast rules around "substantial progress" are difficult to define, generally it means patches should be well underway, with a recent patch posted in the past two weeks, ideally with several community reviews, tests passing or nearly passing, and a clear path to getting the feature completed within the timeframe of Feature Completion Phase. Almost-working patches posted for the first time at 11:59pm on November 30 unfortunately won't cut it. :-) Neither will brand new initiatives starting on December 2 or later. Though ultimately, it will be up to the core committers to decide on any "borderline" issues. We also understand that there is some ambiguity around what constitutes a "feature" or not, and will work on a separate blog post to discuss that.

The hope is that this new release phase will both give the folks working so hard on various major strategic initiatives a bit more time in which to complete their work, and also help narrow the scope of overall development efforts in order to help us focus more as a team as we begin preparing for Drupal 8's release.

Here is a diagram showing an overview of the overall Drupal core release cycle, and where Feature Completion Phase fits in. Initiative owners and others who have already achieved their Drupal 8 feature goals are encouraged to use Feature Completion Phase to get started on their Clean-Up Phase tasks early.

Release funnel
Phases of development, represented as a funnel gradually getting smaller as fewer and fewer patches are accepted. In Development Phase, anything goes: major new APIs, new features, etc. Feature Completion Phase allows for tying up loose ends on features that are already committed, or significantly in progress. Clean-Up Phase is for stabilization, better consistency, and completing conversions to new APIs. Polish Phase moves to focus on the upgrade path, performance optimization, and improving docs. Finally, during Release Phase, we crank on critical bugs until we release!

Of course, it's not possible to provide more time to complete Drupal 8 features without also impacting the remainder of the release timeline. Therefore, Code Freeze will be moved out 3 months as well to July 1, 2013. Drupal 8 will be released when there are no release-critical issues remaining.

I want to thank each and every one of Drupal 8's 960+ contributors for all of your astounding efforts so far. Keep up the great work!


Damien McKenna (not verified):

This is great news for me personally, I've been so busy with D6 & D7 contrib work that I've not had time to contribute much to D8, so the extra time will help make time available to help more on core.

Right now there are 118 pages of open D8 issues, which is very easy to get lost in. IMHO it would be *really* helpful if the various initiative leads & heavy contributors could collaborate on compiling a set of their highest priority issues, and then maybe get this page(s) prominently linked to from the Drupal core project page; this would help people who have an hour or two to spare could more easily find items that might be of interest to them, rather than wading through the aforementioned 118 pages of issues.

Shannon (not verified):

That said, updated roadmaps & feature-related milestones would make life easier for all. I'm a big advocate for this kind of communication even if it takes time away from dev.
just my .02$

Ryan Cross (not verified):

So, we're just formalising code/feature slush?

I'm a bit torn - I'm excited there is more time for more awesome-ness to get into Drupal 8, but I'm quite disappointed that getting that awesome-ness is now further away.

It is also a slippery slope when a "strict" cut off date keeps getting pushed back.

I think many people in the community were looking at late 2013 as a likely release date, and now it seems it will be most likely be into 2014 before we see D8 :(

webchick (not verified):

No, Drupal 7's "code slush" was different in that it was a whole-sale shutting off of features except from a handful of specifically picked-out exceptions. And what we learned from that exercise is that if people didn't have an interest in that list of hand-picked exceptions (or if their pet feature wasn't in the list), they generally flitted off and found something else to do with their time. This left over 300 critical issues to be fixed by a skeleton crew of core developers, which led to both an 18 month code freeze and incredible widescale burnout.

The new "Feature Completion Phase," on the other hand, still respects the "strictness" of Feature Freeze (if you didn't start your feature before now, sorry, but you missed your window for D8), but it also respects those contributors who've been working their asses off for the past several months on Drupal 8 awesomeness, but for whatever reason fell a little short.

The impact this has on the overall release timing is unknown. While we'll definitely add more code and thus more bugs to fix, but the hope is that we'll also provide further incentive for feature developers to stick around and help with clean-up tasks in the longer term, whether that's to get the issue thresholds under control, or to help fix up APIs that their features rely on, or what have you. The criteria for the release hasn't changed, so the timing of 8.0 is going to depend entirely on how many people stick around for the "less fun" parts of the release: Clean-Up and Polish phase.

So, bottom line: if you're interested in a 2013 release date for Drupal 8, get involved and start helping to fix the release-blockers. There's both one-on-one mentoring and">self-paced curriculum available to help get started!

rooby (not verified):

This is great, I was really hoping to hear something like this for the sake of all the great features that are currently underway.

Shannon (not verified):

I may not have a complete vision, but to me it sounds like that the process has changed for the better...

Feature freeze - decide on all your features, and they better be good & working well enough to call "mostly done"
Code freeze - code better be up to snuff & start polishing/prepping for release

new way:
Feature freeze - decide on features & have a good vision for how they will be refined technically
Feature complete - your features are technically stable & api's are ready/working
Code freeze - focus on upgrade paths & prep for launch (security, docs, etc etc etc)

This new approach makes the assumption that there needs to be a refining stage between feature freeze & code freeze and I think it provides the necessary "breathing room" to take a feature and improve it before code freeze.

Me like :)

Larry Garfield (not verified):


You mean that page? :-)

I very much welcome this change, as a lot of really super important "we've been building toward this for a while" lines of work are almost-but-not-quite-ready. This buys them more time to get things lined up, so that we don't ship a mostly-but-not-actually-completed system.

"Doing it right is no excuse for not meeting the schedule" is a bad way to run an open source project, so I'm glad we're being flexible about such things.

yched (not verified):

The post doesn't mention UI changes. My understanding is that they're allowed until string freeze ?
Which according to the graph, would be RC1 ?

eigentor (not verified):

I also feel torn. If this means, that core maintainers are generally merciless in saying: would have been great, but D8 > D9, sorry for stuff that does not meet the above guidelines, good.

But if it all gets a little too slushy which made the D7 cycle a management nightmare, so hm.