One of the most complicated aspects of Drupal has always been the upgrading of your Drupal website to the next major version. Part of this complexity is rooted in the diverse ways you can build and arrange your content in a Drupal website. It’s great to have that utility but it makes it difficult to provide a universal “upgrade now” button that works for everyone.
Additionally, there has always been a significant amount of drive to innovate with the Drupal platform, and as such, each major version has brought with it monumental changes to core systems and features. This has kept Drupal relevant in the marketplace for more than 15 years but has made sticking with the platform as a developer and a website maintainer require a lot of effort.
Thankfully, there is a good reason to believe that when the next major version of Drupal comes around, Drupal 9, the upgrade process will be significantly less challenging.
Continuous Innovation Model
This model for continuous innovation in the Drupal platform is a fundamental change to the overall approach to governance of the project. Whereas in the past major upgrades involved many years of siloed development work usually resulting in massive disruptions to the contributed module space in the new version, as well as hosts of backward compatibility issues - going forward it should not. Hopefully.
This new model is centered around three main concepts: semantic versioning, scheduled releases, and experimental modules in Core.
Per Dries’ own blog post on continuous innovation:
- Semantic versioning: a major.minor.patch versioning scheme that allows us to add significant, backward-compatible improvements in minor releases like Drupal 8.1.0 and 8.2.0.
- Scheduled releases: new minor releases are timed twice a year for predictability. To ensure quality, each of these minor releases gets its own beta releases and release candidates with strict guidelines on allowed changes.
- Experimental modules in core: optional alpha-stability modules shipped with the core package, which allow us to distribute new functionality, gather feedback, and iterate faster on the modules' planned path to stability.
Regular Deprecation and Updating
In general, this change in design patterns and project management feeds into the new aspect of Drupal that will affect the timing and nature of a major upgrade in a big way. That is the gradual adding of new API’s and features and the related deprecation of old code at the same time.
Here is how Dries puts it in his blog on easy Drupal upgrades:
We will continue to introduce new features and backward-compatible changes in Drupal 8 releases. In the process, we sometimes have to deprecate the old systems. Instead of removing old systems, we will keep them in place and encourage module maintainers to update to the new systems. This means that modules and custom code will continue to work. The more we innovate, the more deprecated code there will be in Drupal 8. Over time, maintaining backward compatibility will become increasingly complex. Eventually, we will reach a point where we simply have too much deprecated code in Drupal 8. At that point, we will choose to remove the deprecated systems and release that as Drupal 9.
Flip the Switch for Drupal 9
So, when we think about what the workload will be for upgrading your Drupal 8 website to Drupal 9 in the future, it might not be as painful as previous upgrades. This estimation certainly hinges on your website being kept current with changes in the codebase throughout the release cycle, but at least you can plan for that work ahead of time. All things considered then, if you haven’t upgraded your Drupal website to version 8 yet it seems like it isn’t a bad idea to do so now.