Planning for Drupal 9 and Beyond

Justin’s recent post about the product approach and Drupal's new release cycle got me thinking about what upgrading to Drupal 9 will really look like from a more technical standpoint. There's already lots of information out there explaining this new feature. I think there are some misconceptions about what it means for Drupal projects though, so let’s take a little look under the hood.

Background

To understand what the process of updating to Drupal 9 might look like, you'll need to know a few background terms. If you already know what "semver" and "deprecation" mean for a software project, you can skip ahead to "Preparing for Drupal 9".

Drupal now follows semantic versioning. Semantic versioning—semver for short—is a format for assigning numbers to releases. This number signals a promise about the compatibility and/or stability of a release. A semver tag has three parts, a major version number, a minor version number and a patch version number, all separated by periods. For example, a recent version of Drupal was tagged 8.4.0. For this release, the major version number was 8; the minor version number is 4; the patch number is 0. A common misconception is to think that after 8.0.9, one must have 8.1.0, but it’s perfectly acceptable to have a release number like 8.0.107.

What do major, minor and patch mean? We'll look at each from least to most significant.

A patch release signifies a fix.

They are usually composed of small, isolated fixes. When Drupal is on version 8.4.0 and releases version 8.4.1, this indicates that it is a patch release. It means, "nothing in your code needs to change, we just fixed some bugs". These might be security fixes, so you should update to these releases as soon as possible.

A minor release signifies new features and deprecations.

These are my favorite. They're the ones filled with all the sunshine and rainbows. A minor release adds new features and code to Drupal. This might mean an experimental module becomes stable as the Workflow module did in 8.4.0 or—my personal favorite—a new experimental module, like JSON API, might be added to Core. A minor release is an opportunity for Drupal's maintainers to clean things up, to keep Drupal fresh and to ensure Drupal keeps up with the needs of modern applications. It's also an opportunity to deprecate parts of Drupal Core. A deprecation is when a part of Drupal Core gets moved to the graveyard. It will be maintained for security fixes and bugs, but you shouldn't use that part of Drupal any more. It's usually an indication that there are new, better APIs or best-practices you should follow. A minor release says, "we've made things better, we've cleaned stuff up, and we didn't break your stuff yet."

The graveyard of deprecated APIs

A major release signifies incompatible changes.

They can be a cause for celebration or an ominous cloud on the horizon. They're a critical event in Drupal's lifecycle. A major release is a signal that says "Warning: Your Stuff Might Break!" In some software, it might mean you need to rebuild your project. In Drupal 8 and beyond, thankfully, this shouldn't be the case. The maintainers have made a promise that says, "if you're not using deprecated code, you can update without rebuilding." In the past, like from Drupal 6 to Drupal 7, that wasn't the case and things definitely broke.

Preparing for Drupal 9

So, you know what a deprecation is, and what a major version release means. You know that the promise of Drupal's new release cycle is "if you're not using deprecated code, you can update without breaking things." But did you catch the caveat? If you're not using deprecated code. It's here that I believe the most misconceptions lie. I believe that many have confused this promise to mean that projects can be updated to Drupal 9 without a hitch. That the upgrade will be relatively routine.

The truth is that it's really up to you to make it routine and not something to fear.

How you approach your Drupal software project means that this major event in Drupal's lifecycle can be either a midlife crisis or a coming-of-age.

I said earlier that all the sunshine and rainbows are in the minor version releases. That's because you get all the goodies for free. Underneath the hood though, you need to be aware of what's being deprecated. Every time something is deprecated, a little technical debt is added to your project. You should pay that debt as soon as possible. A deprecation is a warning that the code underneath is going to disappear in Drupal 9. It's a warning to module maintainers and project developers that they need to update code that relies upon that newly deprecated API.

This reality is another point in the product approach's favor, as we alluded to in our earlier post. By making an ongoing investment in your project, you can address these deprecations as they happen so that when you're ready to upgrade to Drupal 9, it will be as painless as any other update.

The Prettiest Rainbows Come After a Little Rain

A select few sites will be able to proudly announce their upgrades to Drupal 9 the day it's released or soon after. Many won’t be able to move so quickly.

Knowing that Drupal 9 will break things relying on deprecated code and knowing that many modules won’t have been updated ahead of the release (such is life in open source), many sites will have to be patient. How patient depends on whether they’ve made an ongoing investment in their platform and kept up with deprecations in their custom code. They’ll be able to upgrade even faster if they have been model citizens in the Drupal community by reporting—and hopefully fixing—contrib dependencies on deprecated code too.

So, is this just like every other major Drupal release? Absolutely not! Gone forever are the days of completely rebuilding your site with every major update. Gone are the days of needing to migrate your own content to your own site. What this means is that you’ll just have to sit inside and wait or go play in the rain, fixing some bugs and updating some outdated dependencies, before you get to enjoy the Drupal 9 rainbow.

Here are some helpful links to stay up to date with deprecations:

• Drupal Core documentation on what constitutes a deprecation.
• A super useful list of what's being added, changed and removed in Drupal Core. I check this regularly.
• A twitter bot that tweets items from the list above.
• A somewhat dense list of deprecated code in Drupal Core