Problem/Motivation
With the following issues
-
#2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches →
-
#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning →
-
#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:
- Switch to the new
CURRENT
#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates →
- 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
- 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:
- 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 →