Drupal core has just announced a new major release schedule. Major releases will come out every two years and be supported until at least two more major versions have been released. (i.e. for at least four years).The new schedule will provide Drupal websites with a reliable foundation of support and security while allowing a longer window to update to new major versions.
This marks the first major change to Drupal core’s release cycle for seven years, so it’s worth some background on how we got here.
With the release of Drupal 8.0.0 in 2016, we started to release patch versions every month, and a new minor every six months. Previous versions of Drupal core didn’t have the concept of patch and minor releases, so this was a completely new process, but it’s one that we’ve stuck with since.
However, what we didn’t have a plan for in 2016 was how to manage new major releases. All we knew was that we didn’t want to keep doing major releases like we’d done previously with Drupal 8, 7, 6 and earlier. Major releases would drop some backwards compatibility layers and deprecated code, remove some old database updates, but the rest was still to be defined.
During Drupal 8, we updated a full major version of Symfony from version 2 to 3 without releasing a new major version of Drupal core. This led to more disruption in minor releases than we would allow now, so we decided not to do that again.
However, without updating dependencies to new major versions, this means that any one major version was stuck on the same ones it started with. Both Drupal 8.9 and Drupal 9.5 had shorter EOLs that core committers were comfortable with, driven by the EOLs of Symfony and CKEditor4.
Unless we wanted to assume security responsibility for outdated versions of Symfony or CKEditor 4, we had no choice but to drop support when they did. This led to a rush where all contrib modules and all sites needed to go from one major version to the next within the space of around twelve months. Many people will still be in the middle of this rush with Drupal 9.5 to 10.0.
While we knew this was a problem from around the release of Drupal 9.0, solving it was a bit harder, and required solving several complex issues:
1. Version dependencies
We needed to ensure that new major versions of Drupal were on the most recent versions of its dependencies. Drupal 10 was the first release to achieve this, using both Symfony 6 and CKEditor 5. This required a major effort to jump from Symfony 4 to Symfony 6, providing bridges between the two where we could. As well as a complete rewrite of our CKEditor integration from version 4 to 5.
2. Dual-version support
We needed to figure out how to support two major versions for a much longer overlapping period. With Drupal 8 and 9, while the EOLs came up very quickly after the new major release, it also meant that modules only had to worry about supporting two major versions for approximately one year, it also meant that we would generally not try to update minor versions of dependencies or add support for new PHP versions.
The two year overlap for major releases, combined with a major release every two years, means that we will always be supporting two major releases, all the time (as well as working on the development branch for the next one sometimes.
Our first idea was to just extend security support for the older major release for an extra year, however this runs into three problems:
PHP’s three year support cycle meant that if you don’t add support for new PHP versions for two years, you barely have security coverage. The PHP team appears to have realized this is a wider problem for downstream projects, and might be extending security support from three years to four.
Also, since new APIs and deprecations will be added every six months in the new major version, over two years this massively increases the likelihood that contrib modules won’t be able to support both core versions with a single branch.
One possible solution was to allow for unscheduled minor releases, for example to update to a new minor release of a dependency if it dropped support for an older version of PHP. However, a site that hasn’t done a minor update for 18 months suddenly faced with a new minor release might not be able to apply that easily.
The path forward
The solution we eventually came up with was to continue releasing ‘maintenance’ minor releases for the older major version. These will contain a subset of issues committed to the new major release, mostly PHP compatibility issues, API additions, and dependency updates. The hope is that this will allow contrib module developers to more easily support both major versions by reducing divergence over time, keep core up-to-date with dependencies, and allow sites to stay up-to-date with newer versions of PHP. All of these should combine to make it easier (or at least, not harder than now) for sites to move to new major versions when they’re ready, just with a longer timeline to do so.
Join our mailing list and you can stay this informed all the time.
Don't be a stranger.
Keep up to date by signing up for our newsletter. It’ll be fun, we promise.