[Meta] Determine how available updates for modules should be handled if they are not compatible with the current version of Drupal core

Created on 20 August 2019, almost 6 years ago
Updated 6 June 2025, 26 days ago

Problem/Motivation

With the following issues

  1. #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches
  2. #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning
  3. #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time

We will not be able to tell if a module is compatible with a specific version or even a major version by the prefix 8.x- or 7.x-.

When all these issues are done a new contrib module created after these changes could have these releases:

  • 1.0.0 that is compatible with Drupal 8
  • 1.1.0 which compatible with Drupal 8.8 and above(not drupal 9
  • 1.2.0 that is compatible with Drupal ^8.8 and 9
  • 1.3.0 that is compatible with only Drupal 9

Currently with the metadata in the update xml from Drupal.org there would be no way of telling if these releases would work with the current major version of Drupal.

If a site is running Drupal 8 should they be shown all these updates?

Should we do #3074998: Add explicit information about core compatibility to update data so that Drupal core can filter out some of these?

In these example releases above any one of these updates could be a security release that makes the previous releases insecure.

If we decide not to show releases that are not compatible with the current version of core we should probably show them in any case if they are security releases.

If we decide to show all releases regardless of whether they are compatible with the current major version of Drupal core should there at lease be some message to tell the site owner that they will have to upgrade to the next major version of Drupal to update the module.

It could be possible for site that some of the contrib modules haven't been updated to Drupal 9 and some have and some are only compatible with Drupal 9. If the available updates report shows all of these without any indication of what state each module is in this could be very confusing.

Proposed resolution

In the near term we need a solution for #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time and the fact that all modules will no longer have core: 8.x in their info.yml files. If don't make any change except to use the CURRENT option that drupal.org offers for update XML the user will likely be shown contrib updates that are not compatible with there major version of Drupal(8 for now) without any indication of this.

Step 1: Completed 🎉

As first step we should:

  1. Switch to the new CURRENT #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates
  2. In #3074998: Add explicit information about core compatibility to update data add a new core_compatibility value for each update. This is will be based on core_version_requirement, or if not available, it will be based core: 8.x
  3. Display a message for each available project update that displays the core compatibility range based on 1) actually available Drupal core updates the update module has retrieved from the update server and 2) the core_compatibility for the project update xml (see above). For example:
    Requires Drupal core: 8.8.3 to 8.9.1

    This is now done and committed to 9.0.x, 8.9.x and 8.8.x branches:

  4. In this first step no modules will be filtered out of the list. This will mean hypothetically you could get projects updates with the message like:

    Requires Drupal core: 9.0.0 to 9.0.5

    In the near term this is very unlikely because 1) Drupal 9 is not out so no module should be compatible with it but not Drupal 8 and 2) 9.0.0 should be compatible with 8.9.0 for modules not using deprecated code. Therefore any module that is compatible with 9.0.0 because it remove deprecations should also be compatible with 8.9.0. So the project would likely have this in the project xml: core_compatibility: ^8.9 || ^9 or core_compatibility: ^8.8 || ^9.

Now complete!

Step: 2

After the above is we should determine if we want to filter out updates that aren't compatible with either your current core minor and/or your current core major version

Step 3

Determine if there is a way to display the update compatibility in a way that considers not just core compatibility but also other module compatibility (e.g. PHP version, module dependencies, etc) and other composer dependencies (e.g. #2494073: Prevent modules which have unmet Composer dependencies from being installed ).

Remaining tasks

TBD

User interface changes

Available updates changes described/shown in linked issues.

API changes

None, Drupal.org XML changes in #3074998: Add explicit information about core compatibility to update data

🌱 Plan
Status

Active

Version

11.0 🔥

Component

update.module

Created by

🇺🇸United States tedbow Ithaca, NY, USA

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇨🇦Canada Liam Morland Ontario, CA 🇨🇦

    Updates that are listed under "Not compatible" on admin/reports/updates/update should not cause the status report to have a "Module and theme update status" "Out of date" warning so long as there is still a supported version installed.

Production build 0.71.5 2024