It seems (correct me if I'm wrong) that there are some classes or services that must be used in relevant cases in Drupal 9 that are not present in Drupal 8.

For example, New in Symfony 4.3: Simpler event dispatching Symfony\Component\HttpKernel\Event\RequestEvent in place of Symfony\Component\HttpKernel\Event\GetResponseEvent.

Same with temporary session storage and more.

This means that if these features are used in a module, the module can only be compatible with one of these core versions; but it seems like a complete waste to manage two codebases at this point, since the versions are still very similar.

What is the correct way to manage this compatibility in one module, and has this question been addressed by the Drupal 9 release team?

  • You can write modules which are compatible with both Drupal versions. Those event classes mentioned were deprecated in Symfony 4.3 but still can be used for all Symfony 4 versions.
    – 4uk4
    Commented Oct 25, 2020 at 13:28
  • Deprecated doesn't mean they don't exist anymore; it means they will be removed in a future release.
    – apaderno
    Commented Oct 26, 2020 at 9:20

2 Answers 2


Yes, this has been addressed by the core maintainers. You are safe if your module doesn't use any APIs deprecated until Drupal 8.8/8.9:

Drupal 8.8 was the final release to introduce new deprecations that will be removed in Drupal 9

A quote from the Drupal release team: https://groups.drupal.org/node/535670

You should wait to remove deprecations introduced in Drupal 9 until you prepare for Drupal 10 and don't need Drupal 8 support any longer.

So beginning with Drupal 8 you can manage compatibility for two Drupal versions at the same time.

  • Drupal 9.0 is the same as Drupal 8.8, but 9.0 removed (almost) everything that was deprecated in 8.8.
    – anonymous
    Commented Oct 26, 2020 at 21:05
  • There are also little differences that make some code not work in both D8 and D9 at the same time. In some cases this requires a conditional statement to test the version and execute version-specific code. A more general solution, as we move to D9.1 where there ARE API changes that are not compatible with D8, is to use semantic versioning to maintain separate minor branches for each core minor branch. The vendor code, like Symfony, is always going to be out-of-sync with Drupal releases.
    – anonymous
    Commented Oct 26, 2020 at 21:27

The solution is to keep doing it the old way. For example the Commerce module keeps doing those the symfony 3 way and it works for both D8 & D9.

Alternatively, you could upgrade your D8 site to symfony 4.4. See Allow Symfony 4.4 to be installed in Drupal 8.

API changes

Symfony 4.4 API will be supported.

and do it, the new, symfony 4 way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.