Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 294336

Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

$
0
0

Problem/Motivation

Because of #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches, Drupal 9 may need to retrieve modules that start with 8.x-. The update module is not currently aware that modules starting with 8.x can be compatible with Drupal 9. Also once as part of #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core Drupal also need to retrieve modules that have semantic versioning releases and don't start with 8.x

Drupal.org now offers a new update xml feed /current that returns both 8.x- modules but also all the new semantic version modules that will be available.

We can't simply switch the /current feed because it does not have the same metadata for projects and releases.

Proposed resolution

  1. Update requests should no longer request information from URLs that have \Drupal::CORE_COMPATIBILITY(8.x) as the final path segment. This should be replaced with 'current'. For example, a request that previously requested https://updates.drupal.org/release-history/paragraphs/8.x will now request https://updates.drupal.org/release-history/paragraphs/current
  2. The contents of /current has a somewhat different structure than what was returned by requests to /8.x, The update module and its tests will need refactoring to reflect those changes.
    • The following tags are no longer provided, the information should be parsed from the version tag instead: version_major, version_minor, version_patch, version_extra
    • recommended_major (which differed depending on the API requested) has been removed. This was only used to determine which major version should be used for available updates if the currently installed version is not supported. Instead the next major version that is supported, as determined by supported_branches. Since currently contrib modules don't have branches that have minor version the supported branches should be the same.

      For core which does have minor branches this will not distinguish between minor core branches. This the same functionality that the update module currently provides for core since the current XML only sends recommended_major not branches.

    • supported_majors replaced with supported_branches, which includes core compatibility for non-semver version numbers.

      In addition to determining the major version should be used as the target major for updates, all updates that are in unsupported branches will not be shown.

Remaining tasks

Follow-ups
#3100115: The update module should recommend updates based on supported_branches not majors
#3100386: Create contrib update module test cases that use semantic versioning

User interface changes

API changes

Data model changes

Release notes snippet


Viewing all articles
Browse latest Browse all 294336

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>