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.

Comments

Submitted by Ryan on 26 February 2018

Permalink

Both of these suggestions are good ones! Thank you for thinking about how to make the drupal community better for sites with limited budgets.

Submitted by tedbow on 1 March 2018

Permalink

Thanks for the article. I wonder if we should encourage contrib authors to make sure they have automated tests running against "Pre-release / supported". Automated testing on Drupal makes this pretty easy to set this up(confession I probably don't have this set up).

Then in addition to this a new contrib module could be made that creates new module status(or uses the current status page) that would get this information for each module on your site.

The module could provide information such if modules have tests up for multiple branches and the results of these tests. It could even monitor the Drupal core releases RSS feed and send warning emails to the site owner when the next alpha/beta/rc comes out with the status of the testing of the modules on their site.

Of course running you own automating testing against future core releases is better but probably many Drupal 8 site owners won't do this.

This may also encourage site builders not to use module that don't have automating testing setup on Drupal.org

I have not research this so for all I know this already exists ?

Submitted by Rick Pine on 2 March 2018

Permalink

Another factor is local environments. There are so many ways to set up a local environment, and sometimes it difficult to know what is causing something to break. Is the upgrade not compatible with my setup? Would it not break if I were testing it on my production environment? It may not be realistic but it sure would be nice if there was a "standard" local environment by which everything (core and contrib modules) were tested against. That way if you have a problem, you could at least rule out your environment being the cause.

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.