Drupal 10 deprecation status summary

The Drupal Association is running a report weekly on all Drupal 9 compatible contributed projects to check for deprecated API uses for compatibility with Drupal 10. This summary and the detail pages are using the raw data from that report to help act on the results. The current displayed dataset is #141 from 2022-07-31T12:04. All the (very, very) raw source data is available. Out of the 8520 projects analyzed, there are three big categories of results: pre-scanning problems that prevent us from looking for deprecated API uses; scanning results and project release status once the code is marked compatible.

Resolve pre-scanning errors: 1086 projects

Projects where there are problems installing the code with composer or Drupal. There are a variety of reasons, but this means that no deprecation checking is possible for them yet, until those are fixed. Some of these are artifacts of how the testing is done and may not be fixable in your project (for example, extra PHP extensions required that are not available or newer PHP main version required). We may not be able to fix scanning of those projects. However many of the problems are fixable in the projects.

Fix deprecation errors found: 6175 projects

Projects that have deprecation checking results with errors to fix. These could still include parse errors found in the process of deprecation checking, but most of the errors found are real deprecated API uses. We further segment these errors into Drupal and not Drupal deprecated API uses. Most of the Drupal ones are even covered by drupal-rector automation (thanks to Palantir.net funding) to fix them automatically as much as possible. There are also a number of third party API deprecations, some of which we segment out for easier tracking. Use Upgrade Status locally to verify your progress fixing these problems.

Release as Drupal 10-ready: 1259 projects

Projects that fixed all incompatibility errors, including updating the info file are in this category. The final steps are tagging releases so people can use the compatible version of the project. Any tagged release is better than a non-tagged dev release, but the best is a stable release of course.