Problem/Motivation

Both #3102724: Improve usability of core compatibility ranges on available updates report and #3113992: The 'Update' page has no idea that some updates are incompatible would benefit from being able to tell a site admin the latest available update that could be installed, given the current version of core on the site.

For (hypothetical) example (if all the other issues were backported all the way to 8.7.x right now):

  • Site is currently on 8.7.11 core.
  • Site has redis 8.x-1.2 installed.
  • Redis 8.x-1.3 is compatible with 8.7.x
  • Redis 8.x-1.4 is latest/recommended release, but only compatible with 8.8.*

We'll soon have code that detects 8.x-1.4 is not compatible, wants the user, hides download link / update-me checkbox, etc.
But it'd be nice to at least be able to update them to 8.x-1.3 (e.g. via the UI), which would still be compatible with 8.7.x core.

Proposed resolution

Add logic (presumably to core/modules/update/src/ProjectCoreCompatibility.php) to figure this out.

Use this logic to enhance the UI of both the Available updates report (admin/reports/updates) and the update-my-site-via-the-UI form (admin/reports/updates/update) to help site builders make better choices.

Remaining tasks

  1. Decide what to do:
    1. TBD
    2. ...
  2. Land #3102724: Improve usability of core compatibility ranges on available updates report which adds some necessary API this would build on
  3. Implement it
  4. Update / add tests
  5. Reviews
  6. ...

User interface changes

TBD.

API changes

TBD.

Data model changes

Probably none.

Release notes snippet

TBD.

Comments

dww created an issue. See original summary.

dww’s picture

Title: [PP-1] Add logic to figure out the latest/recommended release a site could update to with the currently installed version of core » Add logic to figure out the latest/recommended release a site could update to with the currently installed version of core
Issue summary: View changes
Status: Postponed » Active

#3102724: Improve usability of core compatibility ranges on available updates report landed.
In theory, this could move forward now (although it's not critical, so it's probably going to be on the back burner for a while).

xjm’s picture

I'd say this is major considering the valuable impact of this improvement.

That said, we might also want to take a step back and consider how much more of what's essentially Composer/dependency management functionality we want to reimplement in the Update module. It's worth considering whether we want to adopt #3005229: Provide optional support for using composer.json for dependency metadata first, so that then we could use Composer APIs to support the dependency management calculation we'd be doing for this issue. Edit: Or, since that issue needs to be optional at first for the continuous upgrade path, maybe we could add it alongside this one but still use Composer to do the number-crunching here. I didn't dig into what exactly it'd require.

Finally, I'm also adding #3100115: The update module should recommend updates based on supported_branches rather than major versions majors as a related issue. It's not exactly the same issue -- modules could increase their core compatibility requirements without adding new support branches, or vice versa -- but there is some overlap since under semver it's a best practice to increase minor requirements in minors and major requirements in majors.

xjm’s picture

Version: 9.0.x-dev » 9.1.x-dev

Potentially a minor-only addition.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.