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

Last summer, I blogged about how I think about Drupal release date planning, tying it to the Gartner hype cycle and the corollary Drupal mood cycle.

The release timeline I laid out in my previous blog post was a Drupal 8 release 18 months after Drupal 7 had achieved the “Plateau of Productivity", the point in time where developing in Drupal 6 seems mostly pointless due to the maturity of Drupal 7.

At that time, I said that I felt that Drupal 7’s “plateau of productivity" was about 6-9 months away. Today, almost 9 months later, I think that by any reasonable measure we are currently there. There are over 300,000 live Drupal 7 installations, which represents nearly 50% of all reported Drupal sites. The top Drupal modules all have Drupal 7 releases, the vast majority of which are either stable releases or release candidates.

Having reached the “plateau of productivity" also means that I feel comfortable announcing the Drupal 8 release timeline (after catch and I talked about it). Without further ado, here is how the rest of the Drupal release cycle breaks down:


  • December 1, 2012: Feature freeze. No new features are allowed (unless specifically exempted), focus turns instead to API and UI clean-ups and polishing of existing features.
  • February 1, 2013: Code freeze: focus on bug fixes, stabilization. No API changes, instead focusing on bug fixing, preparing for release, and getting the count of critical bugs down to 0.
  • August, 2013 (DrupalCon Europe 2013): Drupal 8 released, to wild, international fanfare. :-)

This means that Drupal 8 is 18 months away. Time to shift Drupal 8 core development into higher gear!

The ~6-month window for bug fixes laid out here is obviously much shorter than the 18-month window for bug fixes we ended up having with Drupal 7, but the hope is that the issue count thresholds that we’ve introduced this release will ensure this process is much shorter than in Drupal 7, since we’ll be going from approximately 15 down to 0, rather than approximately 300 to 0.

This timeline also means that if there are Drupal 8 initiatives you’d like to see happen, or other specific features or things you want to see fixed in Drupal core, now is the time to make those things happen. If you’ve never helped with Drupal core development before and would like to, stop by IRC during Core office hours, or join us at DrupalCon Denver. There will also be plenty of other sprints at DrupalCon around various Drupal core initiatives, and you can always start your own!

See you in Denver and in the issue queue! :-)


Chris Weber (not verified):

With a 12/1/12 deadline for new features, Now is also the time to get involved in the coding effort. With the goals that are itemized by the initiatives it feels like there's either not enough time or just enough time to get everything done that we want in D8. What's a our issue triage plan for things that aren't going to make the cut?

DjebbZ (not verified):

Good decision, Dries!

The more Drupal waits, the more its competition sharpens and gets dangerous. Combined with the fact that WSCCI is going well, I'm confident about August 2013!

Carlos (not verified):

I hope that on August 2013 Drupal 8 will be released with WYSIWYG in core.

Hans van den Berk (not verified):

Exciting news! I just might be able to upgrade from D6 to D7 by that time. (Mostly kidding)

AJ (not verified):

Although the plateau of productivity might apply to the core of Drupal, it is far from the case with the modules.

I never used Drupal 6 but started with 7 as soon as it was released. I still cannot do what I want to do with it as many of the modules I need do not have stable D7 versions. Going to 8 would be no advantage for me as the module development lags so far behind the core development. (Despite the number of people who took the D7 pledge).

Thomas Svenson (not verified):

Great news. Now we have dates to look forward to.

Just a few things I am wondering about. The big difference with D8 is the core initiatives. What is the status of those, are all looking to make D8 and if so what will the come with.

Some of them, such as CMI and WSCCI, are pretty big changes that will also affect much about everything else in core.

CMI for example is about moving configuration from the DB to files. Will this happen automatically for existing features or will they have to be rewritten too?

Is there any deadline when you and catch decide if an initiative will be included of not before Dec 1st?

Lastly, it would be great if there could be a dedicated d.o Drupal Core blog that was easy to follow and where you, core co-maintainers and core initiative owners post regular updates to. Now they are just posted everywhere, making it really difficult to find and keep up with everything important.

Gábor Hojtsy (not verified):

On the question of whether initiatives get in or not, its not a binary question. Many HTML5 improvements are in, many things are refactored thanks to D8MI, etc. These are likely very hard to pull out in any case, and were built with usefulness in mind even if the eventual high goals are not reached. So some portions of (almost) all initiatives will get in I'd say.

CMI changes will not happen automatically, such changes come with sizable API changes. Similarly, WSCCI is about to introduce some big changes. Part of the motivation to have a feature freeze after which existing APIs can be applied to existing subsystems is that people can continue conversion of core to the new APIs and polish what we have instead of racing to get even more stuff in.

For a central place on initiatives, your best place is, for larger core announcements

ash (not verified):

It is to early to talk about Drupal 8. Some of Drupal's modules are still in early stage of development. I think these modules will take at least 7 to 8 months to get stable. The Drupal community is still learning about new features of Drupal 7.

Beep (not verified):

I disagree. I disagree quite strongly.

I think the focus is wrong here. Instead, I think the first priority should be to get Drupal 7 working: there is no point in creating a new version if the old version doesn't work in fundamental areas. All this does is to undermine the credibility of the new version (as well as frustrating users).

Let me give you an example of something that should be fixed before we start talking about having reached a plateau: the new metatags module.

To my mind this is a fundamentally important module and should be part of core (but that's another issue). I don't think Drupal 7 can seriously claim to be at a plateau without having fully functioning metatag control. And I presume the fact that Acquia co-sponsors this module means that you agree it is important.

So what's the problem here? Well, it's three fold:

* First, there are bugs. For instance, the functionality to control the tags on the front page does not work. Seriously--you can't properly control the metatags on the front page of your website. There are many other bugs--this is just an example of a critical bug.

* Second, the open graph protocol tags (which are vital if you're going to control how you are represented on Facebook) are under-specified. Key meta data cannot be added to web pages.

* Third, due to Drupal core bugs, some meta-tags are not exposed for editing. These release blockers are known and documented. They have apparently been fixed in D8, but not D7.

In other words, this is not a simple quick fix. It is one that need concerted effort and some level of coordination (not least at the core level).

Now sure, the module is alpha and the guys behind it have worked incredibly hard, and what it does do is great, and I'm really sorry to pick this module as an example, but it's such a great illustration of what is not being attended to. However, as a community, we need to get our existing stuff sorted before we move on.

So instead of your timetable, let me suggest something else: fix all bugs/release blockers, and so on within the next six months. Then--and only then--when D7 is working as intended and all of the important modules have a **full** release (no alpha, beta, release candidates--full release), then set the timetable to release D8.

rooby (not verified):

To some degree that might be valid but on the other hand, if we wait and wait and wait for everything to be 100% stable (ie. never) Drupal 8 will come out in 2034, maybe, by which time people will have moved on to something more current.

There are definitely some problem areas in Drupal 7 but we still need goals for Drupal 8. If there is nothing to work towards people tend to work with less direction, which usually accomplishes less.

Look at the amount of new Drupal users constantly coming on board. Surely there are enough of us to be able to handle core and contrib. Just as there are a lot of people focused on progressing Drupal core, there are also a huge amount of people who rarely touch Drupal core but spend hours on contrib.

We need to be able to stabilize the current and move forward with the new at the same time. Doing either one on it's own for too long is a recipe for disaster.

Beep (not verified):

My issue as much as anything is prioritization. I'm not against D8 development, I simply don't want to be stuck at D6 while all the work is happening on D8.

Dries has identified that we have reached "the point in time where developing in Drupal 6 seems mostly pointless". This is a great milestone and everyone is to be congratulated. But it's really painful to be forced to stay with D6 (especially when there won't be an out-of-the-box D6 to D8 path).

So while I'm happy that we're looking forward, I would also like to see a timetable for fixing the things that are wrong. In particular, I want to see things that are critical fixed.

I don't see how, without some sort of timetable or bigger initiative, we're going to get this stuff fixed. Take the example I've given (and I'm sure there are many others). Metatags are a fundamental piece of functionality--as I've said, I think this should be a core function. The module is co-sponsored by Acquia (which suggests to me that someone thinks it is important) and yet we have a combination of module bugs, under-specification, and core bugs keeping a crucial piece of functionality from the 300,000 live D7 sites.

Without someone like Dries taking the initiative in this area (or appointing someone to push this stuff through), this sort of stuff is never going to be finished.

moshe weitzman (not verified):

One of the the most crushing and cruel aspects of open source is that people don't work on what you want them to work on. Another inconvenient truth is that Drupal developers are more productive in in the months before a deadline.

There are people who like working on core and are not interested in working on metatags and similar modules. This feature freeze date is for them. Further, there are business folks who like predictability and planning. The August 2013 date is for them.

Beep (not verified):

I agree business folks like predictability (and I agree with your other comments too).

However, business folks also like functionality--especially in crucial areas such as metatags (sorry to keep repeating myself... but it is a good example). I'm not sure how giving predictability without addressing functionality does anything for the business community or the wider Drupal community.

And for those who talk about Drupal moving forward to stay ahead of the competition, I'm not sure how putting Drupal into a constant state where it never works--the "old" version doesn't work because we're focused on the new version and the new version doesn't work because we're still working on it--offers any benefit against the competition. Indeed, I would argue that it just makes *functional* competition more attractive.

chx (not verified):

File a bug report. You are off topic here and you will not get any help here because your rant makes no sense and needs a lot of clarification before it becomes an actionable bug report.

Also, critical, lol. Do you know what's a critical bug? When simpletest accidentally wipes your database. We fixed that. When upon upgrade you lose your node bodies. We fixed that. And so on.

Beep (not verified):

The issues are known. The bugs have been reported by others. I am not after help. I have mentioned the specifics here simply to illustrate my point (which rooby and moshe seemed to understand perfectly well, even if they did not agree with my point of view).

I am sorry that engaging in conversation and putting my perspective forward as a non-geek business user has clearly offended you so greatly.

Gareth (not verified):

I hope there will be a Drupal 6 to Drupal 8 upgrade path included in the plan.

I am struggling to convince clients to upgrade from Drupal 6 to Drupal 7 at the moment, if they know Drupal 8 is only 18 months away, I think I will find it even more difficult to pursuade them.

Gábor Hojtsy (not verified):

Well, you'll likely not be able to use Drupal 8 in August 2013 unless you want to run a blog like this one. Note that Dries announced this today because (among other things) major Drupal 7 modules reached a stable state that people can consistently rely on them. We are over a year after Drupal 7 was released. So think of Drupal 8's usefulness in real site scenarios somewhere between 2013 August and 2014 September (if it progresses on the same pace). That is 2.5 years from now.

A Drupal 7 to Drupal 8 upgrade path is going to be included (as always) but don't expect a Drupal 6 to Drupal 8 upgrade path for core or any contributed modules. You can either do a rough upgrade to Drupal 7 (that does not need to be pretty right just retain your data) and then Drupal 8 or consider this a migration task (much much more common) and just migrate your existing data to the new version / modules skipping Drupal 7.

catch (not verified):

If you're interested in an upgrade path direct from Drupal 6 to Drupal 8, you should help with #1052692 - using migrate module for major version upgrades.

Core won't ship with an upgrade path from Drupal 6 to Drupal 8, but if the Drupal 7-8 upgrade path was using migrate, then at least some of the work for a 6-8 upgrade path would already have been done.

If that core patch doesn't land, migrate module is still a good way to approach this.

Bojhan Somers (not verified):

It's great that we have a better idea, how we should schedule our larger activities. I am not so concerend with Drupal 7, rather than Drupal 8. Let me put on a few of the six thinking hats (Edward de Bono)

Restraints, will power activity (Green hat)
During the Drupal 7 cycle, having a clear goal to work towards was very important to fuel creativity and activity. This deadline should help with some more forced momentum, which will get many stalled issues to think beyond the boundaries they already set, to new ones which can hopefully resolve them. With the addition of the thresholds, its far more clear what is keeping us from releasing.

Initiatives, no new ones? (Blue hat)
What does this mean in terms of our process, currently a few of the Initiatives are stalled. Realistically they should get into shape the next 3 months if they still want to put stuff in. Which would probably also mean any new initiative, would need to be announced within the next 3 months, since there are few that can accomplish there MVP with less than 6 months.

What if momentum doesn't pick up? (Black hat)
We can all recognize the fact that there is little momentum, from the sporadic spurts of activity on initiatives a side. There are simply to few major changes in core, for a large proportion of our users to see the use in using Drupal 8. This is where it jumps into UX, what if we see no significant improvement in Drupal 8? I know the answer, there has to be - but I am not sure we are publicly addressing how to make that happen at the moment.

That's all for now :) I feel this is the right time to set this deadline, its always a bit difficult - but it should definitely force more momentum. I do hope, we discuss more in depth how to move the stalled topics.