aleksip.net

Improving Drupal’s minor version upgrade experience

Twice a year the new Drupal upgrade model makes me both excited about new features and worried about the possibility that the sites I maintain will break. I think there are some ways how the upgrade experience could be made better.

Things that could be improved

I have already written a couple of blog posts (1, 2) about the new upgrade model, detailing things that have caused and could continue to cause problems.

The main points made in those posts are:

  • Security support is only provided for the latest minor version, and there are two minor version releases each year.
  • It is a big challenge for contrib to keep up with changes, new features and new experimental modules in core.

As a consequence:

  • A minor version upgrade can cause sites using contrib projects to break.
  • Drupal 8 sites need more resources to maintain than previous major versions of Drupal.
  • It is not clear if it is always possible to maintain a working site that is covered by security support.
  • These issues make Drupal 8 less attractive for smaller site owners currently on a previous major version of Drupal.

Improvement idea 1: Extend security support to cover the previous minor version

Extending security support to cover the previous minor version would give contrib more time to fix possible issues. It would also make maintaining sites less resource intensive, increasing interest in adopting Drupal 8.

This would of course mean more work for core committers and the security team, so I don’t know whether the idea is realistic or not. But Dries ‘liked’ the idea when I mentioned it on Twitter, so that makes me hopeful!

I have opened an issue suggesting this on Drupal.org and would love to see discussion there.

Improvement idea 2: Provide a new way to find out how contrib projects are affected by a new core version

Currently there are two ways to find out if a new core version breaks your site. The best and only completely sure way is to test the new core version on the site. Another way is to browse through the issue queues of all contrib projects used on the site, looking for issues related to the new core version.

It would be nice to be able to get a list of all contrib projects that have been found to either work or break on a new core version. I believe this functionality could also be useful in the Automatic Updates initiative, to determine whether an update can be made or not.

A lightweight implementation of this feature would be to tag issues in a commonly agreed way. If for example a contrib module was found to be broken by changes made in Drupal 8.6.0, an issue could be opened and tagged ‘Breaks in 8.6.0’. That way all projects broken by changes in 8.6.0 could be easily found using the ‘Search issues for all projects’ page.

Being able to easily find out which contrib projects have been reported to break in the next minor release would possibly help getting issues fixed quicker. This data could also be used to gain insight on the ways contrib uses core that result in breakage. It would also provide interesting statistics on how common breakages are.