Skip to main content

Multiple version compatibility in Drupal--managing the tradeoffs

November 25, 2021
Body paragraph

If you're a seasoned Drupal module developer, or even a relatively new one, it's hard not to like the fact that, starting with Drupal 8.7.7, it's possible for a single version of a module to be compatible with multiple versions of Drupal core. Suddenly, maintaining your module became way easier. It's noteworthy enough that the process of making a module work with the Drupal 9 release was incomparably easier than any previous major version upgrade. But beyond that, you could actually maintain a single version for both Drupal 8 and 9, or both Drupal 9 and 10. How great is that?

But - and there always is a but, isn't there? - it's not quite so straightforward. There are some significant tradeoffs to sticking with a single release branch for two major versions of core. I'll look at a couple here - deferred refactoring and missed improvements - and ways to mitigate them.

Pitfall #1: deferred refactoring

One of the modules I've maintained for Drupal 8+ is Features. While not nearly as widely used as in Drupal 7, Features still has a reported install base of around 29,000 in Drupal 8 and 9, placing it somewhere in the top 100 or so modules by usage.

To get Features working in Drupal 9, I did what a lot of Drupal module maintainers did--the minimum.

I focused on what was strictly necessary to make the module work in the new version. Even that was a fair bit of work, spread over many issues and several releases. We had to upgrade the automated tests, fix up the way we generate new feature modules, and lots more.

Sure, at the same time I also took a pass or two through the issue queue and applied fixes where I could, addressing a few outstanding bugs not explicitly required for Drupal 9.

The combined result was a lot of improvements to the module, some of them addressing longstanding issues. What I didn't even begin to do, however, was ask: how would we do it now?

When we started work on the Drupal 8 version, keeping the same code and approaches we had in Drupal 7 wasn't remotely an option. Drupal had been rewritten from the ground up, and contributed modules had to keep pace.

Now, though, sticking with what we did in Drupal 8 definitely is an option, and it's an alluring one.

The bulk of work on the current Features version was completed early in the Drupal 8 cycle. At the risk of understatement, a lot has changed in the meantime. In Drupal core, there was a whole Configuration Management 2.0 initiative that introduced various improvements during the Drupal 8 cycle. In contrib there are some great modules now that hadn't so much as been imagined when we started in on Features.

Then there's what we've learned through using and developing Features itself.

How would I approach Features if I was writing it from scratch today? Very differently.

For starters, I'd make it a lot more modular. There are pieces of Features that duplicate what other modules do, sometimes better than Features does.

But I don't have to do any of that--and so I won't.

Don't get me wrong, I still think Features is a fine module for many uses. It just won't get the attention it might have if stasis wasn't an option.

Pitfall #2: missed improvements going forward

There's a flip side to the fact that a Drupal 8 module could run on Drupal 9. It's that a Drupal 9 module had to still run on Drupal 8.

There are workarounds that in some cases make it possible to take advantage of newer functionality while maintaining backward compatibility. But short of such additional work, a release that's compatible with both Drupal 8 and 9 is stuck in some version of the past. Module developers can't add anything that comes with Drupal 9--any of the improvements in Drupal 9.1 or later minor releases.

At the same time, they can't remove anything that's deprecated in the Drupal 9 cycle and slated to be removed in Drupal 10, because doing so would mean their code wouldn't work in Drupal 8.

And here's the clincher--by the time a lot of developers began making their modules compatible with both Drupal 8 and 9, Drupal 8 was already on its way out. Drupal 8 reached end of life this month. At this point, the ability for a module to work in both Drupal 8 and 9 is kinda academic.

Worse--all these still-maintained Drupal 8 compatible modules may contribute to a mistaken sense that it's safe to stay on Drupal 8. Compatibility with an obsolete core version looks less like a feature than a bug.


It might sound like I'm tilting against multi-version releases. Calling for discipline--resist the temptation! Cut a new branch as soon as a new major version is available! Refactor to use the best of what's added throughout the new cycle! Remove deprecated code in each Drupal 9 minor release, so the code is already compatible with Drupal 10 when it's released!

But that's not really my point. Instead, I'm thinking there's probably a middle ground. Maybe, for some site and module maintainers, that looks like:

  • After the work of the a new version upgrade, ride for awhile the relative ease of multi-version compatibility.
  • But don't leave it forever. When you're ready, cut a new branch and see what improvements the new core version brings.
  • At the latest, cut the new release branch when the old major version of core is no longer supported. For Drupal 8, that time is now.

In sum? Multi-version compatibility makes the work of maintaining code more manageable. It gives Drupal users quicker access to the modules they know and rely on from past versions. We can appreciate it for what it is, while not losing sight of what it isn't: a magic cure to the problem of keeping software current.