I presented on the overall status of the Drupal 10 initiative in December at DrupalCon Europe. Then posted an update about the initiative one week ago on the Drupal Core blog.

More recently I worked on making Upgrade Status work meaningfully on Drupal 9 with Andrey Postnikov. Released Upgrade Status 8.x-3.5-alpha1 today to let you test this out. (You may need to use composer require --dev phpspec/prophecy-phpunit to make your phpunit setup complete).

How is this different from prior releases of Upgrade Status? It should run very similar on Drupal 8 as it did before. However prior releases of Upgrade Status explicitly forbid running it on Drupal 9 as the UI was very focused on the transition from 8 to 9. Now the UI elements are adapted and in some cases more general to support running either on Drupal 8 or 9.

Environment requirements are not yet defined for Drupal 10, so that part of the report is intentionally brief. However, we know Drupal 10 will require PHP 8 and the underlying phpstan-drupal library does not work on PHP 8 yet. As a super-important infrastructure piece, I encourage you to sponsor Matt Glaman to make that happen. Even included this link on the module UI.

Should Drupal 9 modules be compatible with Drupal 10 now? Absolutely not! We don't even know the full extent of Drupal 10's API or the final versions of its dependencies. However we do know a lot of deprecated APIs already, some from as far as back as Drupal 8.2.0, and projects can gradually update following those to close the gap with Drupal 10 now.

So running Upgrade Status on Drupal 9 will tell you about .info.yml file incompatibility errors and composer.json incompatibility errors, but I would ignore those for now. The more interesting bits are the already fixable deprecated API uses found that were marked deprecated in Drupal 8 and will be removed in Drupal 10. I installed the top 6 most used modules on a test site, to check the results out and there are plenty you can already help move forward in these modules. Most issues found are related to the legacy deprecated assert methods. It is no problem in Drupal 9 to use them, but those will not be present in Drupal 10 next year. Most have 1-1 replacements, so it would be best to build rector rules for them into drupal-rector and support this transition that way. (Also drupal-rector itself needs to support Drupal 9).

I started to work with the Drupal Association to set up a job to figure out the status of Drupal 10 readiness at this time of the 5000+ Drupal 9 compatible projects. (Similar to the deprecation status data we have about Drupal 8 modules tested for Drupal 9 compatibility). It may sound too early as more Drupal 9 APIs will get deprecated for Drupal 10, the reality is we already know a lot of deprecated APIs including those from Symfony and other dependencies. We can use this early data to help prioritise which deprecated APIs to cover with rectors which would allow us to start posting Project Update Bot issues for those that are Drupal 8 to 10 deprecations and are in unsupported Drupal 8 branches. This would allow us to get a headstart on fixing them, automated as much as possible.

At DrupalCon North America 2021 (less than 6 weeks away!) there will be a dedicated Drupal 10 readiness day where you will be able to learn about the state of the new version and will have a chance to work with the lead maintainers for each area to contribute to Drupal core, the tools and readiness of contributed projects.

I presented The Drupal 10 readiness initiative - here we go at DrupalCon Europe a month ago. While I published my slides with plenty speaker notes right away, the session videos just became public. While the live presentation was a month ago, most of the content is still up to date.

Drupal 9 is expected to have the shortest Drupal major release lifetime in recent history with Drupal 10 planned to be released in the middle of 2022 (next year!) and Drupal 9 end of life by end of 2023. In this session, we discussed what it takes to get from Drupal 9 to Drupal 10 and how are we going to manage this transition. We also covered what we learned from the Drupal 8 to 9 transition (so far) and how we plan to make it better for 10.

Check out the recording:

Do you own an existing drupal.org project that does not yet have a Drupal 9 compatible release? This week would be a good time to take that step and make a Drupal 9 compatible release! I am paying for two tickets to DrupalCon Europe for new Drupal 9 compatible releases. Read on for exact rules!

DrupalCon Europe is in two weeks already! December 8-11, 2020. It offers 4 keynotes, including the Driesnote and the Drupal Core Initiative Leads Keynote (that I help coordinate), 119 sessions in five different content tracks, 4 workshops, interest group discussions, and networking. These are all included in the 250 EUR (no VAT) ticket. I would love to see you there!

Looking at Drupal 9 compatibility data, while 83% of the top 1000 projects by usage already have a release, the others do not. If we look at all the projects, 43% of them have a Drupal 9 compatible release. This is way better than with Drupal 8 was at the same time, but we can still do better! 22.5% of all projects (2177 projects in total) need an info.yml file change and a release, no other changes required. There is a good chance one of those are yours!

The rules of this giveaway are the following:

1. The participating project must have existed before this week.
2. The project must have its first Drupal 9 compatible release this week, before end of Friday.
3. Selection from eligible projects is random.
4. The lead maintainer on the winning two projects will pick who gets the ticket.
5. In case of a pass, I draw another project.
6. I will be using my existing script from the #DrupalCares campaign to track the newly Drupal 9 compatible projects.
7. The script uses the official drupal.org releases dump and takes dates of releases from there.

I'll keep this list up to date throughout the week with who is in the running:

Update: Congratulations to winners: Marcelo Vani for the first Drupal 9 compatible release of CSV to Config and Daniele Piaggesi for the first Drupal 9 compatible release of Prevnext.

DrupalCons are a great way to learn and connect, but they are especially great to meet various people leading Drupal's future direction. DrupalCon Europe in a couple weeks is no execption.

There is of course the Driesnote to get an update on where Drupal's progress is and get inspired about where its going. There is a dedicated question and answer session with project lead Dries Buytaert where you can inquire about topics not covered in the keynote.

The initiative leads provide a glimpse into their respective areas in the Drupal Initiative leaders keynote. This is a great way to get to know the leaders and learn more about their plans and where you could help.

Various initiatives have dedicated sessions: the Core Automatic Updates Initiative Update and the Configuration Management Initiative 2.0 session provides updates on the progress made and gives you a look forward. There is not one but two sessions about the new experimental Olivero frontend theme in Drupal 9.1.0: Designing for chaos: The design process behind Olivero and The Olivero theme: Genesis and Update on Drupal 9's Newest Theme.

A practically inevitable future milestone is Drupal 10. In The Drupal 10 initiative, here we go I will cover where we are in preparing Drupal 10, what you can expect and where you can be involved. On the way to Drupal 10 is our support for PHP 8. While not specifically about Drupal core's progress, the PHP 8: What's new and changing will showcase the new version of the programming language.

For the future of Drupal, the people leading and the technology being built is at least as interesting as the platform we are collaborating on. You might have heard that merge requests and issue branches became generally available on drupal.org yesterday (yes!). In Drupal.org Update - The latest collaboration tools to help you build Drupal (panel), you can learn more about the current state and future of the platform we use to build Drupal itself.

Also of wide interest is the effect of end of life Drupal versions: Jeremy Andrews and Mike Meyers will cover Drupal 7 and Drupal 8 end of life.

These were just the pre-planned sessions. The real involvement possibilities are at Birds of a Feather discussions where you can be directly involved with core discussions, see how hard problems are deconstructed and solved. Most BoF slots are still open for submission, but there will be various covering core's future. Also contribution events will happen all week where you can learn Drupal development and any other kind of Drupal contribution based on your interests. I expect contribution topic groups forming around Symfony 6 compatibility, removing jQuery UI components, CKEditor 5, the Claro admin theme and Olivero frontend themes and so on.

These are just the core focused sessions out of 119 sessions offered at the event in five tracks. Also there are even 4 in-depth workshops included with each ticket. Hope to see you there! Check out https://events.drupal.org/europe2020 for more information.

Photo credit Boris Baldinger from DrupalCon Amsterdam.

Drupal 8 and 9 core were already made compatible with Composer 2 back in May. Last week the Drupal package repository (packages.drupal.org) rolled out full support for Composer 2 as well. While Michael Anello did Drupal vs. Composer 2-alpha2 benchmarks in July and Malabya also did an even more detailed benchmark in July, various things have been improved in Composer 2 since July and the packages.drupal.org improvement should also show.

Inspired by numbers posted by Konstantinos Skarlatos from a simple scenario to the #composer drupal.org/slack channel today, I went ahead and attempted to produce a reproducible scenario you can also try at home. I included all commands to copy-paste. There are no external dependencies other than a PHP executable on your command line and curl to download files as used. For reference, my PHP is as follows (definitely not the latest):

$ php -v
PHP 7.3.11 (cli) (built: Jun  5 2020 23:50:40) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies

Set up the latest Composer 1 and 2 locally

First let's grab the latest Composer versions locally. This will avoid any confusion as to which version is used when.

$ curl https://getcomposer.org/composer-1.phar --output composer-1.phar
$ php composer-1.phar -V
Composer version 1.10.13 2020-09-09 11:46:34

$ curl https://getcomposer.org/composer-2.phar --output composer-2.phar
$ php composer-2.phar -V
Composer version 2.0.0-RC1 2020-09-10 15:39:45

Install Drupal 9 with create-project

Make sure that we are not using cache and ask composer to profile itself. This got me two Drupal 9.0.6 copies, again to separate our testing environments properly.

$ php composer-1.phar --no-cache --profile create-project drupal/recommended-project composer1site
[...]
[9.3MiB/41.02s] Memory usage: 9.35MiB (peak: 197.23MiB), time: 41.02s

$ php composer-2.phar --no-cache --profile create-project drupal/recommended-project composer2site
[...]
[12.5MiB/18.29s] Memory usage: 12.48MiB (peak: 13.71MiB), time: 18.29s

The time is cut in half but the peak memory usage had an even bigger drop to less than 7% of the Composer 1 memory peak with Composer 2.

Adding and removing a Drupal module

You only do site creation once for a site. Let's add and remove a Drupal module! Konstantinos tested with Metatag which sounds like a good one to do. While Metatag only has Drupal project dependencies, the savings are likely similar for projects with 3rd party dependencies.

$ cd composer1site
$ php ../composer-1.phar --no-cache --profile require drupal/metatag
[...]
[629.4MiB/65.35s] Memory usage: 629.36MiB (peak: 1557.29MiB), time: 65.35s

$ php ../composer-1.phar --no-cache --profile remove drupal/metatag
[...]
[450.9MiB/47.98s] Memory usage: 450.85MiB (peak: 1377.67MiB), time: 47.98s

$ cd ..

$ cd composer2site
$ php ../composer-2.phar --no-cache --profile require drupal/metatag
[...]
[13.7MiB/3.13s] Memory usage: 13.67MiB (peak: 14.23MiB), time: 3.13s

$ php ../composer-2.phar --no-cache --profile remove drupal/metatag
[12.1MiB/0.18s] Memory usage: 12.1MiB (peak: 12.49MiB), time: 0.18s

Ok, that is pretty jaw dropping. Adding Metatag goes from 65 seconds down to 3 seconds. Removing Metatag goes from 48 seconds to 0.18(!) seconds. Memory usage goes down to 1% (one percent!), from a gigabyte and a half to 12-14 megabytes.

What does this mean for Drupal?

Given the explicit support on drupal.org, you should be able to use Composer 2 for your Drupal site builds whenever you are comfortable, maybe already in the RC stage or later on as it gets stable. Assuming any composer plugins you need are compatible. Drupal sites are often using cweagans/composer-patches, which is Composer 2 compatible in the dev version, but did not have a release yet. You can change your composer.json to have "cweagans/composer-patches": "1.x-dev" and do a composer update to get the development version that is already compatible.

Many are not using composer at all to build their sites. However, an increasing number of drupal.org projects require external Composer dependencies to function. Based on last week's data from Ryan Aslett from the Drupal Association, 12% of drupal.org projects directly have a third-party Composer dependency. Another 6% have a Drupal dependency that in turn has a third-party Composer dependency. So even if we only look at direct and one-level indirect dependencies, 18% of Drupal.org projects require Composer to be installed properly. I also looked at various segments of projects and the ones requiring Composer are very well distributed. 15.2% of the top 500 projects (by usage) require Composer while 16.2% of the top 5000 do. So if you are not yet using Composer to build your Drupal sites, it seems to be only a matter of time. The improvements in Composer 2 should help a lot with its adoption I think.

These improvements will also be crucial for the Automated Updates initiative which has Composer 2 compatibility on their roadmap as well. Signature verification is only possible with Composer 2 and the lower memory and time requirements allow it to be run from web requests.

Finally, the downloadable tarballs of Drupal core are built with Composer 1 currently to make it easy to transition from a tarball based site to a Composer site. Allow Drupal 9 (including dev builds) to use Composer 2, part 2 is open to move that to Composer 2. Unfortunately a sizable blocker to that is Composer's "prefer-stable" setting cannot be relied on to produce a stable release. That would need more discussion and a solid resolution to move forward. There is less than 3 weeks before Drupal 9.1 is locked down, so your feedback there would be more than welcome!