Problem/Motivation
See original discussion in #3108658: Handling update path divergence between 11.x and 10.x for some background and https://www.drupal.org/about/core/policies/core-release-cycles/release-p... for an overview of the new release cycle.
As of Drupal 11, we're starting to release 'maintenance minors' on the previous major branch - the first of these will be Drupal 10.4, released after Drupal 11.0.0.
For a while, we've supported minor releases for one year. This introduces a new problem that we've never had before, and didn't fully think through when we originally decided to issue maintenance minors.
The idea of a maintenance minor is broadly twofold:
1. To enable contrib modules to maintain support for both Drupal 10 and 11 more easily. This means selected API additions can be backported from 11.1.x to 10.4.x
2. To update PHP and JavaScript dependencies, so that it's easier to keep on security- (and bug-)supported versions of those dependencies until 2026, as well as allowing us to support newer PHP versions when they come out, like PHP 8.4
Both #1 and #2 mean that for example when Drupal 10.4 is released, it is likely to be a on a newer version of CKEditor 5 than Drupal 11.0.0. It is also likely to have small API additions and bugfixes not available in 11.0.0 too.
Additionally, a module that adds support for a new API added in 10.4 - let's say an annotations to attributes conversion, or just calling a new method to avoid a deprecation, could reasonably expect to add a core dependency that is >= 10.4 without having to do >= 10.4 || >= 11.0
Now that #3108658: Handling update path divergence between 11.x and 10.x is in, we could add an empty hook_update_N() to 11.1, and backport this to 10.4 to use the new equivalent updates API, and if a site updates to 10.4, then tries to update to 11.0, system_requirements() will prevent the update from going ahead when it finds the equivalent update is missing on 11.x. This would prevent a site from thinking it has done a successful update, then hittting weird issues (and potentially in the worst cases data loss or site downtime) after that, however, it would still be annoying to only be told you can't update to 11.0 when you've already updated your code base, and then have to either roll your code base back to 10.4, or keeping going to 11.1.
Opening this issue to see if we can come up with another strategy, either in code or on d.o or via the release process, to prevent this situation as much as possible.