Contrib.social

Make Automatic Updates Extensions stable!

Open on Drupal.org →
Created on 28 March 2024, 3 months ago
Updated 25 April 2024, 2 months ago

Problem/Motivation

Automatic Updates Extensions is not marked as stable. One reason for that is that we don't know how different modules will handle backwards compatibility and is just more likely to crash your site than updating core. But this problem is not going to change anytime in the near future.

Here are reasons I think we should mark the module as stable, with some small changes I will suggest in the solutions section

  1. The module has been experimental for a long time and we haven't had any bug reports on it for a long time(ever?). I think the code is pretty solid.
  2. The module only has 5 classes including 2 forms
  3. As we added test coverage in the main module we duplicated the coverage in Automatic Updates Extensions as needed.
  4. In #3307369: Validate all changed or updated Drupal projects with Update XML → we moved the validation to ensure that all Drupal project that are staged are actually secure according to Drupal.org's update XML. So even if we get logic in wrong in this module Package Manager would not allow us to install a module that is not supported and secure according to update XML
  5. Package manager also handles all the other general type of validation like making sure the active lock file has not changed since the update has been staged, we have enough disk space, etc
  6. Sites have to update their contrib anyways and will do this directly with Composer or if they don't know Composer they will do it the old fashion way. Automatic Updates Extensions has advantages over both these methods.

    Using Composer directly could let you update to versions of Drupal modules that are insecure or unsupported according to drupal.org's XML.

    Updating by just moving new versions of the Drupal module in directly in place will not handle Composer dependencies. This could actually be a security concern because a contrib module security update may be issued solely to update one if its own dependencies that has it own security release. If the module was originally installed with composer and has its dependencies installed but for whatever reason a new site admin doesn't know the composer way to do things the depencies might NOT be updated.

  7. Some users of the main module might be using because they don't know how to update their site via Composer. Maybe someone made the site but now they are in charge. They may be keeping Drupal core up to date but not updating contrib modules for security releases

Proposed resolution

We should mark the module as stable with the following changes

  1. Mark \Drupal\automatic_updates_extensions\ExtensionUpdateStage as internal, all the other classes are already internal
  2. Add extra warning that updating contrib modules may crash your site depending the on particular module. Suggest that all updates should first be tried locally
  3. (optional) Add a checkbox that user to above warning to make the user acknowledge the risk

Remaining tasks

📌 Task
Status

Fixed

Version

3.0

Component

Automatic Updates Extensions

Created by

🇺🇸United States tedbow Ithaca, NY, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024