Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
We should prevent people updating from 10.6 to 11.2 or lower.
See #3463226: Use the new equivalent updates API to prevent updates from 10.4.0 to 11.0.0 for the equivalent 11.1 issue, exactly the same pattern can be copied from there.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3561087
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3561087-add-equivalent-updates
changes, plain diff MR !14020 - 3561087-10.6.x changes, plain diff MR !14021
Comments
Comment #3
godotislateComment #6
godotislate10.6.x MR https://git.drupalcode.org/project/drupal/-/merge_requests/14021
11.x MR https://git.drupalcode.org/project/drupal/-/merge_requests/14020
It occurs to me now that the test changes might be unnecessary, since the system update itself isn't being test. If so, I can revert.
Also, I noticed that if I started on the 10.6 MR branch and install a new site, then if I update the site to 11.2.x, the requirements warning is not shown. This is because when installing on 10.6, the update hooks don't run, so the equivalent update registration doesn't happen. This is the same as installing on 10.4 and updating to 11.0. Since there aren't a lot of reports of people updating to downgrade versions, this might be fine?
Comment #7
catchI think you found a fatal flaw with the original plan... We could probably add something to system_install() in 10.6 to cover this, but it's another thing we'd need to remember and keep updated. It might not be worth it.
I'm only aware of one report from someone who actually did a downgrade, and that was fairly early on in the 11.0/11.1 cycle.
Comment #8
xjmI think we should plan to address #6 for Drupal 11/12 in a more holistic way, and possibly consider backporting fixes for it for 10.6/11.2 at least so it is addressed for the next six months of security fixes there. I don't think it should block this issue, though, as the most immediate concern is for people who run latest versions.
Comment #9
xjmTagging for #6.
Comment #10
xjmI agree that we can remove the test changes BTW.
Comment #11
godotislateRemoved the test changes in both MRs, added follow up per #9: #3561302: Register equivalent updates on site install
Comment #12
godotislateComment #13
catchGood to go with just the updates now I think.
Comment #14
dwwProbably RTBC as-is, but opened a question about the chosen update N number for the 11.x MR.
Comment #15
dwwp.s. @godotislate: Thanks for discovering the flaw in the approach we've been using, and for opening the follow-up!
Comment #16
godotislate@dww thanks for catching that. I was wondering why there wasn't a 11200, hence why I didn't do 11300, only to realize now that 11200 is above all the other update hooks, including 11100. Applied the suggestions.
Comment #17
catchWe reserve the 000 update hook for major releases, for reasons I can't remember and possibly never fully understood - it has to do with the 7-8 upgrade path and is not really relevant any more. I think starting from 001 is in various docs because of this, but it's definitely fine to use 11300 for minor releases and is what we should do. We only need to leave enough space to have 100 updates in 11.2.x, not 101.
Comment #18
dwwGreat, thanks! This is now RTBC to my eyes...
Comment #19
quietone commented@godotislate, thanks for the fast reply
Comment #20
dwwGood find, @quiteone. Sorry I missed that. Thanks @godotislate for the quick fix.
Comment #26
catchCommitted/pushed to 11.x and 11.3.x and then to 10.6.x respectively, thanks!