In this blog post, we'll have a look at how contributed Drupal modules can remove the core deprecation warnings and be compatible with both Drupal 8 and Drupal 9.
We already have the continuous upgrade path policy which should mean that any up-to-date Drupal 8 module should work with Drupal 9.0.0, either with zero or minimal changes.
Drupal core has a proper deprecation process so it can be continuously improved. Drupal core also has a continuous process of removing deprecated code usages in core should not trigger deprecated code except in tests and during updates, because of proper deprecation testing.
The big problem for contributed modules aka contrib is the removal of deprecated code usage. To allow contrib to keep up with core's removal of deprecation warnings contrib needs proper deprecation testing which is being discussed in support deprecation testing for contributed modules on Drupal.org.
This drupalci.yml will check all the Drupal core coding standards. This can be disabled by the following change:
phpcs: # phpcs will use core's specified version of Coder. sniff-all-files: false halt-on-fail: false
This file also only runs PHPUnit tests, to run legacy Simpletest you have to the following block:
run_tests.simpletest: types: 'Simpletest' testgroups: '--all' suppress-deprecations: false halt-on-fail: false
But if you still have those, you probably want to start there, because they won't be supported in Drupal 9.
Last but not the least if you think the is module is not ready yet to fix all the deprecation warning you can set
As a contrib module maintainer or a contrib module consumer I encourage you to add this file to all the contrib modules you maintain or use, or at least create an issue in the module's issue queue so that at the time of Drupal 9 release all of your favourite modules will be ready. JSONAPI module added this file in https://www.drupal.org/node/2982964 which inspired me to add this to DER in https://www.drupal.org/node/3001640.
I caution any contributed module from following this advice until https://www.drupal.org/project/drupal/issues/3002148 is resolved. At present it is difficult to configure DrupalCI to behave as you for the currently supported branch for Drupal core and also maintain compatibility with future deprecations coming in the dev branch.
Basically we're not ready for this for contrib. There are work arounds suggested by @Mile23 in https://www.drupal.org/project/drupal/issues/3002148#comment-12802118 - I encourage people thinking about doing this to read that issue.
What Alex said. I did this for the JSON API module because we want it to land in Drupal core. But we are running into the problems explained in the issue linked by Alex.
Despite Drupal 9 being announced, Drupal Continuous Integration system is not yet ready for modules trying to keep current with all deprecations for Drupal 9, while remaining compatible with both simultaneously minors with security team coverage (current + previous, ATM 8.6 + 8.5) and the next minor (next, ATM 8.7). Hopefully we soon will be :)
Thanks for writing about this though, I do think it's important that more module maintainers get in this mindset!
DrupalCI always runs contrib tests against the latest core branch. As a contrib module maintainer if I have to make a compatibility change for core minor version then I create a new release and add that to releases notes after the stable release of core minor version e.g. 8.x-2.0-alpha8. I never have to create a new release for the core patch release at least till now but yes I don't know how would I name the new release if I ever have to do that but then again that's contrib semvar issue.
DrupalCI runs against whichever core branch the maintainer has configured it to run against.
If a contributed module wants to remove usages of deprecations, it should probably never do that against the "Development" branch, as there isnt a way for a contrib module to both remove those deprecations, *and* still be compatible with supported or security branches. The earliest that a contrib module should try to remove new deprecations is at the pre-release phase, as at that point we're unlikely to introduce new deprecations.