How did we get to Drupal 9?

Drupal 9 does not represent a great milestone in the traditional sense. It does, but not one comparable in scale to the release of Drupal 8.0 when the entire world cheered and the stock markets rallied. Rather, Drupal 9 represents proof that some decisions were made wisely when the time came to change the release approach Drupal was accustomed to.

Before Drupal 8, every few years a major version of Drupal was released. And with these releases came the joy of getting all the new features and leaving the old behind. But what also came was the pain of upgrading to these new releases. No more, said Drupal 8, which has been steadily introducing new features and functionality with each minor release until now. To the point that we have reached the end of the Drupal 8 release cycle and have gone into Drupal 9 in almost the same way as we've been going from one minor release to another, say, from 8.5 to 8.6. But then what is the difference?

In semantic versioning, minor releases mean that new features can be added as long as backward compatibility is ensured on all existing APIs. This means that even if in 8.5 you realize a public API is stupid and want to change it, you must ensure that in 8.6 it remains functioning. In a deprecated state, sure, but still compatible. Most of the time, these APIs simply delegate to the new, shiny ones. But as time goes on, the codebase gets full of this deprecated code that should not be used anymore. Enter major releases, such as Drupal 9.

Major releases allow the removal of all the deprecated code and instruct developers and users of the software to ensure that they are compatible with all the new APIs and that they ditch the old ones. So, this is exactly what Drupal 9 is doing: removing all the deprecated code from 8.9 and calling it Drupal 9. The two will be identical in many respects.

Why now, though? Why not in 4 years? Or 5? Apart from the growing codebase full of useless code and the increasing difficulty of managing these deprecations, Drupal is also facing the challenge of maintaining its dependencies. Ever since it "got off the island" and started relying on other open source libraries, it also got dependent on their life cycles. Here, the most notable is Symfony. Drupal 8 has been using Symfony 3, whose end of life is set for November 2021, and therefore the end of life of Drupal 8 needs to coincide with that. Upgrading to Symfony 4 would mean breaking backward compatibility, so a new major version of Drupal is also needed. Besides, there are plenty of libraries that stand to be updated as well, such as Twig to version 2. Which is also great.

Where does this leave our book? Everything you will learn in this book will be compatible with Drupal 9. Many of the things will also be compatible with Drupal 8, especially later versions of it, and with slight adjustments. For this reason, going forward, I will refrain from mentioning specific versions of Drupal because it makes less and less sense to do so. Except, of course, when it becomes germane to my point to be specific about the version.