As Dries Buytaert explained in his Plan for Drupal 9 post at the end of 2018 (emphasis mine):
Drupal 8’s biggest dependency is Symfony 3, which has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. Therefore, we have to end-of-life Drupal 8 no later than November 2021. Or put differently, by November 2021, everyone should be on Drupal 9.
Working backwards from November 2021, we’d like to give site owners at least one year to upgrade from Drupal 8 to Drupal 9. While we could release Drupal 9 in December 2020, we decided it was better to try to release Drupal 9 on June 3, 2020. This gives site owners 18 months to upgrade. Plus, it also gives the Drupal core contributors an extra buffer in case we can’t finish Drupal 9 in time for a summer release.
Here we are 14 months later and while most people took the June 3 release date and took it for granted, it is still not guaranteed! However you can help in various ways to make it much more likely!
Late last fall, we focused on defining what it means if we cannot make the June 3, 2020 release despite our best efforts and what is an early indicator that tells us we are going to miss it. First of all, that meant defining requirements for the first alpha release and requirements for the first beta (API complete) release. Also we needed to set some expectations as to when do we want to see the API-complete beta release to give enough time for the ecosystem to test it and find important problems in time. Based on how soon the beta requirements are met, there are three release scenarios and the best case ending in the June 3, 2020 release date for Drupal 9 has a beta deadline in 6 weeks! Yes, 42 days!
Alpha requirements simplified
The key requirements for the first alpha release are simple. We wanted to update the key dependencies: Symfony to version 4.4 and Twig to version 2, as well as remove frontend polyfills that were not needed and remove most of jQuery UI (which were already deprecated in Drupal 8). This gets our most important dependencies up to shape to what will be in Drupal 9. We also made it possible for contributed projects to depend on Drupal 8 and 9 at the same time, so they will not need to branch for Drupal 9 support.
There are two outstanding things for the Drupal 9 alpha:
- Drupal.org does not yet have an automated packaging pipeline that conforms to all the recent composer related improvements and therefore making core releases is error prone. I don’t believe you can help with this at this time, the Drupal Association is hard at work on this.
- Drupal core should use a major version agnostic update feed for projects which is already being provided by Drupal.org but the core code to consume it is still in the works. While this is actively being worked on, reviews are always helpful. This will make sure Drupal 9’s Update Status gets only contributed projects that are actually Drupal 9 compatible, while contributed modules will not need to establish a Drupal 9 branch.
Beta requirements simplified
The beta requirements are a bit more complicated and longer of course because we are looking at being API complete here. Once again, for the June 3, 2020 release date, we need these done in 6 weeks! The issue lists must haves and should haves, however the should have issues should be considered must-have for the June 3, 2020 release date and would only be reconsidered later if that date cannot be met. Here is a simplified rundown of the beta requirements:
- We want to keep dependencies up to date. There is no concrete pressing issue here at the moment that I know, but this really depends on how our dependencies evolve.
- We’d like to remove all the deprecated APIs themselves. Last year I built a graph to track this, and it shows nicely that we are down to half of them remaining (yay!), but still quite enough to deal with. There are various outstanding issues you can help with here.
- We want to make sure people can update to Drupal 9 from Drupal 8 by resolving critical upgrade path bugs. If you cannot update to a later version of Drupal 8 due to some critical bug, then you will be stuck on your version of Drupal 8. Not good. These include views, layout_discovery, taxonomy, menu_content, etc. related issues. All of them need help. If you are on an older version and can reproduce the problems, that is useful. If you have experience in these areas, your input would be useful.
- It will only be possible to update to Drupal 9 from Drupal 8.8 or 8.9, so all older update paths and their tests should be removed. Older versions of Drupal 8 will themselves be unsupported already at the time of Drupal 9’s release. This issue is getting close but needs reviews.
- No new security or data integrity issues should be in Drupal 9. If there are any, they should be resolved. I don’t know of any issues at the moment here.
- The API should be complete. There are no critical API additions or changes that I know of at the moment in this general category.
- We want to make sure people can migrate from Drupal 6/7 to Drupal 9. This needs the remaining multilingual migration paths to go stable. This is an area where we posted several call to actions, but still need your help. There are proposed migration paths for node translations and entity translations that respect revisions but they need at least code reviews to make sure they are good. Otherwise if you had content translations with revisions, the migration will not be correct. Without that, multilingual migrations will not go stable.
- PHP requirements should be finalised. It is likely at this time that Drupal 9 will require PHP 7.3 that is being worked on currently and could use a review.
- Database requirements should be finalised in terms of MySQL/MariaDB/Percona and PostgreSQL. Both issues need data as to which distributions and hosts support certain versions.
- The right security update information should be provided for users taking the one year support cycle and long term support of the last Drupal 8 release. This could also use reviews.
- We should put Drupal’s base theme on a track so that it can evolve in Drupal 9 finally. This involves creating a new stable9 theme and decoupling the core themes from Classy. Various issues to help with here.
- Drupal.org should support multi-core compatibility eg. on project pages, localize.drupal.org, etc. This work is currently deprioritised by the Drupal Association due to the focus on the packaging pipeline blocker that I listed first. Once this gets attention, it will likely uncover core issues to resolve as well.
The two areas that receive the least attention at the moment are upgrade path blockers and the stability of the multilingual migration path, so those two are the most pressing where we need your help!
While the above is a complete rundown of the current beta requirements, it may change later on, so refer to the beta requirements issue later on for up to date information.
What happens if all the above are not done by end of February (in six weeks)
If all goes well, with your help, we’ll be done with all the above in six weeks. If that does not work out, we have a plan B and a plan C. Here is how those options unfold. If beta requirements are only done two months later by end of April, then Drupal 9’s first beta will be released on the first week of May and Drupal 9 is to be released on August 5, 2020. If the beta requirements are only done by end of August (four more months later), than the first beta will be released than with a Drupal 9 release date of December 2, 2020. In this case a Drupal 8.10 may also be released if needed. These dates are spelled out well in the Drupal core release cycle overview. I created this visual to help understand the alternate timelines:
While I think it is reassuring that we have plans for what happens if our initial date targets don’t work out, unfortunately the end of life date at the end of next year for Drupal 8 is not movable because it is based off of Symfony 3’s end of life. So the sooner we can make Drupal 9 happen (while meeting the upgrade and stability requirements) the better. What are you going to work on to help?
Helping with contributed projects
Based on the PHP deprecations our tools can identify, 43% of contributed projects would only need info.yml file updates to be Drupal 9 compatible. An additional 41% of the remaining projects have only issues that are resolvable now (even while keeping support for Drupal 8.7). Solving those anytime between now and Drupal 9’s release (whenever it is) would put us to almost six thousand contributed projects compatible with Drupal 9 on day one! While that is a very idealistic number, helping with contributed projects is nonetheless a great avenue to contribute to Drupal 9 readiness. Help at the Drupal Global Contribution Weekend at end of next week or anytime before and after! I prepared a quickstart guide for this occasion.