Support deprecation testing for multiple branches on contributed modules on Drupal.org

Created on 25 September 2018, over 6 years ago

Updated 19 April 2025, 3 days ago

Problem/Motivation

Drupal core benefits from proper deprecation testing use @trigger_error(... - see https://www.drupal.org/core/deprecation → .

Contributed modules also want to leverage the same system for testing to prove they are up-to-date with the latest API changes and to handle deprecating their own code. However this is tricky because a contributed module typically has to support the current patch branch, the future development branch and the old patch branch which is still security supported. As of 25th Sept 2018 that's 8.5.x, 8.6.x and 8.7.x. If core adds a new deprecation in 8.6.x and new code to support that deprecation (eg. #2996789: Deprecate Drupal\field\Tests\EntityReference\EntityReferenceTestTrait → ) then it is not possible to have passing tests on all three branches. In 2996789 the contrib maintainers argue for the deprecation to be removed from 8.6.x but this only pushes the problem down the line and they'll still have fails in 8.7.x.

Possible solutions

Only add deprecation messages to core at a later date. I.e introduce the new code path in 8.6.x and only commit the deprecation @trigger_error() in 8.8.x. That way when 8.8.x starts to trigger the deprecation the 8.7.x (patch) and 8.6.x (security) branches have the code and everyone can easily move. @alexpott thinks this is a terrible solution because it means new usages of deprecated code will be added to core and we will forget to add deprecations.
We could do solution 1 and mitigate @alexpott's concerns by opening a future deprecation branch (eg. 8.8.x) to commit deprecation messages to but that will increase complexity for everyone working on core especially core maintainer. And @alexpott still thinks this is not a good solution
Contrib needs a way to say ignore deprecations when testing against these branches. So for example a contrib module could disable deprecation testing against the patch and security branch (now 8.5.x and 8.6.x) but enable it against the future dev branch (8.7.x). That way the contrib module can prove they work against the currently support Drupal branches but also be aware of future work coming up. Additionally it would be great to be test any matrix the contrib author would like. I.e. to have testing with and without deprecations against the future dev branch.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task

Status

Needs work

Version

11.0 🔥

Component

phpunit

Created by

🇬🇧United Kingdom alexpott 🇪🇺🌍

Live updates comments and jobs are added and updated live.

Drupal 9

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 3 days ago →
🇬🇧United Kingdom catch
@mglaman linked to https://github.com/phpstan/phpstan-deprecation-rules/issues/81 in slack, which seems like it could solve this at least on the phpstan/rector side. I don't know exactly how, but having the removed in version in a structured way ought to allow us to ignore it conditionally based on something. Test coverage would still show triggered deprecations, but ✨ Adopt #[Deprecated] attribute Active might enable something with that too.

With 📌 Defer disruptive 11.3 deprecations for removal until 13.0 Active , and also OOP hook + annotation deprecations all slated for Drupal 13, but likely to be introduced in Drupal 11, there will be quite a lot of deprecations that could potentially ignored by projects solely focused on Drupal 12 compatibility.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024