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
- Decide what to do:
- TBD
- ...
Land #3102724: Improve usability of core compatibility ranges on available updates report which adds some necessary API this would build on- Implement it
- Update / add tests
- Reviews
- ...
User interface changes
TBD.
API changes
TBD.
Data model changes
Probably none.
Release notes snippet
TBD.
Comments
Comment #2
dww#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).
Comment #3
xjmI'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.
Comment #4
xjmPotentially a minor-only addition.