Drupal 8 promised to change the game for developers and site builders. The release of Drupal 9 is the realization of that promise.

With today’s release of Drupal 9, we thought it would be helpful to look at why this release will be a major milestone for the project.

At Palantir, we’ve been working with Drupal since version 4.7. Personally, I started evaluating the platform with Drupal 4.5. Since then, I have been an active contributor, module developer, and even core subsystem maintainer. I even maintain one module that I originally wrote for Drupal 5.

When previous major versions of Drupal core were released, the upgrade process was, to put it mildly, complicated. Drupal never followed a backward-compatibility policy, preferring to move forward with each release. In theory, this meant a lighter code base and less legacy “cruft” to deal with. In practice, it meant major system rewrites as part of each release. 

In past releases, those changes have included such elements as the FormAPI; multiple rewrites of the menu system; the introduction of the database abstraction layer; putting configurable data fields into core; adding Symfony and the use of services; using Twig for the theme layer. The list goes on.

For site maintainers and module authors, a new major core release essentially meant rewriting large parts of your code base. That would inevitably lead to a lag period after the release, as module maintainers worked to update their code.

On top of that, the rearchitecture of the core system meant underlying changes to data structures, so updating a site wasn’t just about the code. Updates meant modifying the database because of changing content type definitions. Or replacing deprecated modules and techniques with entirely new ones. For these reasons, moving to a new version of Drupal often meant a complete rebuild and migration rather than a software upgrade.

In the Drupal 8 release cycle, leading up to the release of Drupal 9, all of that changed. The project moved to:

• Scheduled releases every 6 months
• Planned deprecations of APIs and code-level elements
• Automated testing and tools for updating existing code

Now, with Drupal 9, we are finally in a position to perform a software update rather than a system rebuild. Tools like Upgrade Status and Rector -- which I have written about previously -- give site and module maintainers tools to audit their code and make the changes more easily. As a result, you can make your sites Drupal 9 compatible while you are still running Drupal 8.8 or 8.9. 

And that provides a level of confidence that we haven’t had before. Instead of advising clients to perform major upgrades every five years or so, we are now in position to support ongoing, incremental improvements. With confidence in the underlying, enterprise-level architecture, we can shift our energy from compatibility to creativity. Dupal 9 makes it easier to focus on the business needs of the entire organization, instead of the technology that powers it.

Drupal Open Source