Drupal 10 deprecation status summary
The Drupal Association is running a regular report to check contributed projects for deprecated API uses and major version compatibility. 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 #109584 from 2024-03-03T12:33. All the (very, very) raw source data is available. Out of the 7882 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.
The project is either marked abandoned or obsolete or both. This means you need to move on from this project either within your current Drupal environment (if a replacement is available) or as part of your upgrade.
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.
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.
Now that a development branch of this project is compatible with Drupal 10, the next step is to tag an alpha/beta/RC or stable version of the project, depending on maintainer confidence in the stability of the codebase. This allows people to use a specific known compatible version of the project.
The project has a tagged release for Drupal 10 which is great. Depending on maintainer confidence about stability of the codebase, the next step is to make a stable (not alpha/beta/RC) release available for this project.
The project is not only declared compatible with Drupal 10 but even has a stable release with that compatibility. Congrats and thanks to the maintainers and contributors!