We just released Drupal 8.6.0. With six minor releases behind us, it is time to talk about the long-term future of Drupal 8 (and therefore Drupal 7 and Drupal 9). I've written about when to release Drupal 9 in the past, but this time, I'm ready to provide further details.

The plan outlined in this blog has been discussed with the Drupal 7 Core Committers, the Drupal 8 Core Committers and the Drupal Security Team. While we feel good about this plan, we can't plan for every eventuality and we may continue to make adjustments.

Drupal 8 will be end-of-life by November 2021

Drupal 8's innovation model depends on introducing new functionality in minor versions while maintaining backwards compatibility. This approach is working so well that some people have suggested we institute minor releases forever, and never release Drupal 9 at all.

However that approach is not feasible. We need to periodically remove deprecated functionality to keep Drupal modern, maintainable, and performant, and we need to stay on secure, supported versions of Drupal 8's third-party dependencies. As Nathaniel Catchpole explained in his post "The Long Road to Drupal 9", our use of various third party libraries such as Symfony, Twig, and Guzzle means that we need to be in sync with their release timelines.

Our biggest dependency in Drupal 8 is Symfony 3, and according to Symfony's roadmap, Symfony 3 has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. To keep your Drupal sites secure, Drupal must adopt Symfony 4 or Symfony 5 before Symfony 3 goes end-of-life. A major Symfony upgrade will require us to release Drupal 9 (we don't want to fork Symfony 3 and have to backport Symfony 4 or Symfony 5 bug fixes). This means we have to end-of-life Drupal 8 no later than November 2021.

Drupal 8 will be end-of-life by November 2021

Drupal 9 will be released in 2020, and it will be an easy upgrade

If Drupal 8 will be end-of-life on November 2021, we have to release Drupal 9 before that. Working backwards from November 2021, we'd like to give site owners one year to upgrade from Drupal 8 to Drupal 9.

If November 2020 is the latest we could release Drupal 9, what is the earliest we could release Drupal 9?

We certainly can't release Drupal 9 next week or even next month. Preparing for Drupal 9 takes a lot of work: we need to adopt Symfony 4 and/or Symfony 5, we need to remove deprecated code, we need to allow modules and themes to declare compatibility with more than one major version, and possibly more. The Drupal 8 Core Committers believe we need more than one year to prepare for Drupal 9.

Therefore, our current plan is to release Drupal 9 in 2020. Because we still need to figure out important details, we can't be more specific at this time.

Drupal 9 will be released in 2020

If we release Drupal 9 in 2020, it means we'll certainly have Drupal 8.7 and 8.8 releases.

Wait, I will only have one year to migrate from Drupal 8 to 9?

Yes, but fortunately moving from Drupal 8 to 9 will be far easier than previous major version upgrades. The first release of Drupal 9 will be very similar to the last minor release of Drupal 8, as the primary goal of the Drupal 9.0.0 release will be to remove deprecated code and update third-party dependencies. By keeping your Drupal 8 sites up to date, you should be well prepared for Drupal 9.

And what about contributed modules? The compatibility of contributed modules is historically one of the biggest blockers to upgrading, so we will also make it possible for contributed modules to be compatible with Drupal 8 and Drupal 9 at the same time. As long as contributed modules do not use deprecated APIs, they should work with Drupal 9 while still being compatible with Drupal 8.

Drupal 7 will be supported until November 2021

Historically, our policy has been to only support two major versions of Drupal; Drupal 7 would ordinarily reach end of life when Drupal 9 is released. Because a large number of sites might still be using Drupal 7 by 2020, we have decided to extend support of Drupal 7 until November 2021. Drupal 7 will receive community support for three whole more years.

Drupal 7 will be supported until November 2021

We'll launch a Drupal 7 commercial Long Term Support program

In the past, commercial vendors have extended Drupal's security support. In 2015, a Drupal 6 commercial Long Term Support program was launched and continues to run to this day. We plan a similar paid program for Drupal 7 to extend support beyond November 2021. The Drupal Security Team will announce the Drupal 7 commercial LTS program information by mid-2019. Just like with the Drupal 6 LTS program, there will be an application for vendors.

We'll update Drupal 7 to support newer versions of PHP

The PHP team will stop supporting PHP 5.x on December 31st, 2018 (in 3 months), PHP 7.0 on December 3rd, 2018 (in 2 months), PHP 7.1 on December 1st, 2019 (in 1 year and 3 months) and PHP 7.2 on November 30th, 2020 (in 2 years and 2 months).

Drupal will drop official support for unsupported PHP versions along the way and Drupal 7 site owners may have to upgrade their PHP version. The details will be provided later.

We plan on updating Drupal 7 to support newer versions of PHP in line with their support schedule. Drupal 7 doesn't fully support PHP 7.2 yet as there have been some backwards-incompatible changes since PHP 7.1. We will release a version of Drupal 7 that supports PHP 7.2. Contributed modules and custom modules will have to be updated too, if not already.

Conclusion

If you are still using Drupal 7 and are wondering what to do, you currently have two options:

  1. Stay on Drupal 7 while also updating your PHP version. If you stay on Drupal 7 until after 2021, you can either engage a vendor for a long term support contract, or migrate to Drupal 9.
  2. Migrate to Drupal 8 by 2020, so that it's easier to update to Drupal 9 when it is released.

The announcements in this blog post made option (1) a lot more viable and/or hopefully helps you better evaluate option (2).

If you are on Drupal 8, you just have to keep your Drupal 8 site up-to-date and you'll be ready for Drupal 9.

We plan to have more specifics by April 2019 (DrupalCon Seattle).

Thanks for the Drupal 7 Core Committers, the Drupal 8 Core Committers and the Drupal Security Team for their contributions to this blog post.

Comments

John (not verified):

You mention PHP7 support for Drupal 7 which is good.
However, how can one know if all modules are compatibles with PHP7 ?
For example this module that I use, is it indicated anywhere on the page or should it be tested manually ? https://www.drupal.org/project/book_title_override
I understand that you collect usage statistics, perhaps you should also collect the PHP version used, as this could be a useful indicator of how much the module has been run with specific PHP versions: https://www.drupal.org/project/usage/book_title_override
Thanks.

Barrett (not verified):

One of the best ways I've found is to make sure your error logging is set to log PHP's E_DEPRECATED error class while you're running php5.6 (by default, Drupal suppresses that error class). That'll at least log cases where code will not be supported in future versions.

Dave (not verified):

I'd like to echo John's concerns about managing module compatibility in D7 especially given the relatively short time scale.

  • Will there be any formal effort to ensure that at least the more popular D7 modules are supported on PHP 7.2?
  • Can PHP 7.2 support at least be mandated as a requirement for security advisory coverage?
  • Will there be any changes to the module listings on Drupal.org to make it easier to check current PHP version support?
  • Is there a release date set for the PHP 7.2 compatible version of Drupal?
Barrett (not verified):

Policy to date has been that the community supports (current - 1) major versions, so D5 was supported until D7 was released, D6 until D8, etc. Keeping to that policy, we'd expect D8 to be supported until D10 is released. I get that we can't reasonably keep D8 alive past the EOL of Symfony 3, but is this considered a one-time break from the current - 1 major version support plan or will we be shifting to a plan of supporting only the current major version (with some brief-ish period of support for the n-1 version while people get onto the current major)?

Adam Weingarteen (not verified):

To "encourage" and "socialize" contrib to be ready for D9, we might add checks to D.O for projects to scan for the use of deprecated functions and flag them on the project pages on D.O. This is a great way to get people looking to contribute to find easy contributions that will make a big impact. The sooner we add this the quicker we can get the community ready!
We can also use the metrics collected to calculate the overall preparedness for D9!

Pasqualle (not verified):

Not prepared for D9 at all, and I really believe we will never be prepared for D9. The main problem is not contrib, but Drupal core.
https://www.drupal.org/project/drupal/issues/2949018
Some of the usage of deprecated classes is not even possible to remove, without a breaking api change.

Contrary to popular belief, updating to D9 will not be easy.

Philipp (not verified):

IMHO the problem is not the migration of the core to a new version itself, the contrib modules are often a real bottleneck.

During the migration from D6 to D7 a few years ago, the probability to find a ported module was quite higher than when migrating from D7 to D8.

Now, often there are alternative modules (which also make sense, due to technological evolution), but no possibility to transfer data/content. It's often the search of a needle in a haystack, to find a reliable, stable (successor-/alternative-) module which supports existing data when migrating a grown website to a new Drupal version.

As a site builder I would appreciate an API (and perhaps a GUI) where I can export data as painless as possible as CSV, JSON, XML, or YAML. Then it would be much easier to modify data if a (successor-/alternative) module require another data structure (if no suitable upgrade path is available). Also a way vice versa should be provided.

Every module should get a special flag, a shield or badge which supports these possibilities. When searching for a module on drupal.org the user should be able to set a filter to find those modules.

These modules should be in every Drupal core, and then contrib modules can as a solid base rely on it:

Just my 2 cents.

Kevin Reynen (not verified):

THANK YOU! I asked the EOL question during the Ask Dries session at DrupalCon Nashville. You didn't have an answer at the time, but I can't tell you how much easier having this so clearly stated this makes my job.

That said ... seeing changes that so many people (including you) have pushed for 7 years like install profile inheritance (https://www.drupal.org/project/drupal/issues/1356276) break yet again with 8.6.0 doesn't give me much hope that the issues we've identified with running hundreds of sites as a service will be fixed in D9 unless something changes.

Our development team spent most of August evaluating Backdrop and contributing to the areas where we found it didn't work well for our specific use case. That use case is building less ambitious websites with a very low TCO. The Backdrop 1.11.x release will include some of those improvements. Seeing contributions come to fruition that quickly and being part of a community that is mainly contributors again has been refreshing, but Backdrop isn't all rainbows and unicorns. There would still be a substantial amount of work to update our codebase and migrate ~1000 sites and the community is still quite small.

If D7 EOL was going to be in 2019, we really only had 2 viable options left; 1) Backdrop for all our sites or 2) a mix of D8 for the largest sites and WordPress for the smaller sites. An EOL of 2021 for D7 gives us enough breathing room to continue evaluating D8 or D9 as the upgrade path for our service, but if nothing changes in the governance or direction of the project it seems unlikely that D9 will meet our needs any better than D8 did.

What would it take to get "Improvements for Running Drupal as a Service" defined as an initiative so it could be managed and funded the way Media, Automatic Updates or Layout have been?

The Univesity of Colorado is not the only large university with hundreds of D7 sites, but we are one of the largest (and clearly the most vocal). We are now painfully aware that our needs differ from the average Drupal using organization and that we didn't participate early enough in the D8 lifecycle.

Rather than focus on the tooling around managing sites that already exists in projects like Aegir or services like Site Factory, what we need is a way to focus resources on issues in Drupal itself like ...

  • Changes to decrease the memory footprint of D8 when running hundreds of sites
  • Problems with maintaining install profiles; both the way they are packaged on Drupal.org and updating sites using them after they've been installed
  • Official support for essential core builds (https://www.drupal.org/project/ideas/issues/2873800)

A well-defined initiative would make it much easier for universities like ours to justify contributing both staff time and $$. The fact we didn't do this for D8 and the end product of those development cycles doesn't work well for our use case should only help make the case for contributing to managers who don't fully understand the technical issues or how to contribute to open source.

Dries:

I remember you asking the question during the Q&A. You were sitting towards the front of the room on the side of the doors. It helped me understand how important this is, and it's one of the reasons why I wanted to provide an update at Drupal Europe. Thanks for your new suggestions; I've to think about these some.

NonProfit (not verified):

Continuing to offer major releases is a sound strategy, as Drupal 8 matures, removing legacy code is certainly the best path forward. Having release dates presented years in advance is very much appreciated and so much better than telling clients, “It will be at least several years … probably.”. However, Drupal 7’s end of life announcement raises significant concerns.

Drupal 8 was released nearly three years ago but only 20.2% of sites report using it. Clearly, usage numbers are not everything; a single enterprise-level site which takes a team of developers a year or more to launch requires significantly more developer hours than hundreds (or possibly thousands) of quick installs. Also, if everyone simply changed branching strategies from Dev-Stage-Prod to GitFlow it would wipe out 1/3 of our sites with zero reduction in marketshare. What is harder to measure, but a much more compelling metric, is community engagement. Things like conference attendance, or number of camps is important, but I focus on what I consider Drupal’s unsung hero — the contrib space.

There are currently 7,247 full projects with security advisory coverage for D7 but only 1,657 bring returned for D8. Zero modules are returned as D8 sandbox projects (https://www.drupal.org/project/project_module). I understand why the decision was made to alleviate the application bottleneck, but we now have a significant number of modules not covered by Drupal’s security advisory policy being used on a large number of sites (File Entity, Job Scheduler, and Feeds each running on more than 100,000 sites while Administration menu reports a whopping 471,662 installs!)

Two of the top 10 most-used modules are incomplete (Webform is in pre-release and Libraries API is considered ported but not usable). As we move down the list things look worse. Nearly one-third of the most-installed modules (32 of the top 100) are either in pre-release or marked ported but not usable for D8.

I believe’s Drupal’s phenomenal success is largely based on it’s robust and secure contrib space. At this area, D7 seems to outshine D8. Let’s focus our attention on rectifying this well before D7 is EOL.

Let’s encourage:
- the accepted standard to be for production ready modules to maintain security coverage
- more community members to review applications
- the return to the use of sandboxes for developmental work
- highlighting similar modules on project pages
- the documentation of new best practices when older well-established modules go unsupported

Thank you.

Raghwendra (not verified):

Dear Dries,

Thank you to share the journey of Drupal. Much helpful for individual and companies to decide the version for Drupal. This we will be help us to move on Drupal 8 or wait for Drupal 9. We can also suggest our client to keep sites on Drupal 7 until November 2021. Great!

Thank you!

AndrewMRiv (not verified):

A great read!

My favorite bit will be the ease of upgrading from Drupal 8 to Drupal 9 in comparison to previous major upgrades. It is really cool knowing that Modules developed in D8 will work in D9 so long as no deprecated APIs are being used.

Thanks for all the hard work!

Add new comment

The content of this field is kept private and will not be shown publicly.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.