[policy, no patch] Remove old update hooks prior to each major version (Drupal 10 and later)

Discussed a bit with @Berdir on Slack. I wrote:

discussing the real world implications is good. One of the first things I implemented for Thunder was a better test of the update process going back to the first release of Thunder 2. It worked after some fun with update ordering. But I totally agree there is a cost to supporting 8.0.0 to 8.x.x and that that cost is worth discussing.

the problem is I don't understand how we can advise how to move all the code together. ie. if you are on 8.3.0 and we say you have to go to 8.4.0 before going to 8.5.0 what should you be doing with your contrib at the same time?

@Berdir's response on slack was

good question, I don't know, there is no generic answer for that I guess. newer core minors might have broken contrib modules, and newer contrib modules might require a certain core version. But doing a large update like that is a big challenge either way

Marked #3068632: Increase \Drupal::CORE_MINIMUM_SCHEMA_VERSION()? as duplicate.

I think we need to come to a decision here prior to releasing Drupal 9, so moving to plan and critical like the other issue was.

There are probably two questions here at least:

1. Do we want to drop support within 8.x for updating from very old versions (for example could 8.8.x only support updating from 8.4.x or higher?). This seems non-critical but might help with test performance and maintenance.

2. Drupal 9 should definitely pick a cut-off point from very old 8.x versions - i.e. we should probably only support updating from 8.7.x or 8.8.x to 9.0.x and explicitly drop support and tests for updates prior to 8.6.x or 8.7.x. We might also want to require 8.8.x and above once we get to 9.2.x

Just noting that when \Drupal::CORE_MINIMUM_SCHEMA_VERSION is bumped, it looks like the message that's displayed will also need to be rejigged slightly:

foo module cannot be updated. Its schema version is version, which is from an earlier major release of Drupal. You will need to migrate the data for this module instead.

I suppose we may need to distinguish between incompatible starting schemas before and after 8.0.0, since the steps for resolving that problem are different in each.

Took a quick look at https://www.drupal.org/project/usage/drupal to see how it looks now.

There are still approximately 25k sites on 8.5, but closer to 5k on 8.4 (and also around 5k on 8.3, 5k on 8.2).

8.5 only dropped out of support a couple of months ago, and 8.5.5 usage went down from 5.5k to 5k in the past month.

The highest usage 8.6.x release is 15k for 8.6.16, vs. 42k for 8.7.3.

From that I think we can say the following:

- the vast majority of sites are staying on a minor branch with security support.

- a small but noteworthy number are falling 1-5 months behind minor branch EOL, but eventually catch up (approx ~25k at the moment).

- every minor release leaves behind ~5k sites, my guess is a lot of these are never-updated installs that were fresh at the time.

If we project those numbers forward, by the time we get to 9.0.3 / 8.9.3, we'd have about 25k sites left on 8.7 with the vast majority on 8.8 or 8.9, and then a long tail on older versions who may not have ever updated by that point.

So if we wanted to require an update to 8.8.x prior to updating to 9.x, then it's not going to be an issue for the vast majority of sites, and even if there are 100k sites on older Drupal 8 minors on the day 9.0.0 is released, probably 25-50k are just running a bit late, and the other 50-75k will have never been updated since they were installed. All of them have six more months of 8.8 support, and a year of 8.9 support, to get to those versions prior to updating to 9.x

Then ignoring the usage stats, 8.7.x drops security support the day 9.0.0 is released, and 8.8.x will be supported until 9.1.0 is released. Therefore it's quite reasonable to want to update from 8.8.x to 9.0.x (skipping 8.9.x) but not so much from 8.7.x or lower.

----

Given all that, I think we should require people are on 8.8.x before they can update to 9.x, this minimises the variables so should help us with troubleshooting bugs too. It doesn't rule out some kind of contrib compatibility issue that we're only able to resolve in 8.9.x, but we're not at that point yet to find out.

For dropping older 8.x updates in 8.x, I think we can safely drop all updates <=8600 based on the usage stats (dropping <=8600 means 8.5 sites can still update). If we do that in 8.9.x, then even 8.0.0 sites could update to 8.8.x, then go straight from there to 9.x, but I'd be fine with doing it in 8.8.x too if we can get a patch RTBC - will be non-trivial given the database dumps etc.

We should also drop post-updates corresponding to those versions, but we have zero documentation on which version they apply to, so will have to figure out when they were added via git history to do that... might want to start adding some docs to the updates to indicate what they apply to.

Given all that, I think we should require people are on 8.8.x before they can update to 9.x, this minimises the variables so should help us with troubleshooting bugs too.

This does seem a valuable risk reduction. 👍

Moving this to needs review now there's an actual proposal in the issue summary.

To close this issue, we'd need a change record and documentation updates explaining the policy for 8-9 updates, then follow-up/implementation issues for both #2 and #3.

I think this makes a lot of sense. Anything that reduces the complexity of the Drupal 8 to 9 upgrade path is a good idea and ensuring that we only have to deal with 8.8.x or 8.9.x -> 9.x.x does that. +1 from me.

I think if we do find

some kind of contrib compatibility issue that we're only able to resolve in 8.9.x

then we probably want to try very hard to find a way to make it resolvable in 8.8.x

This would also need a release note for each of the 8.8, 8.9, and 9.0 release notes.

At a minimum, and in the future, we could adopt this for every two major versions (so D11 drops D9's upgrade paths and migration sources, and D10 would drop D8's if we don't drop them in D9). I need to think more about the implications and disruptions of D8 specifically, which will have had 6+ years of updates instead of the 3 or so we're likely to have in the future, and lots of... let's call it learning experience about what we actually need to do with our D8+ APIs.

An extra issue here is we currently have a lot of open, critical, upgrade path issues - most of which are 8.5-8.7-ish updates. We absolutely should not remove those updates from 8.x until they're fixed. I don't think this should stop us from removing them from Drupal 9 though to minimise the number of Drupal 8 versions that people try to update from.

However we might also want to consider an interim step where we commit a patch that implements hook_update_last_removed() to 9.x, then a follow-up to actually remove the updates later - this would mean less conflicts trying to backport fixes and similar.

Postponed #3087644: Remove Drupal 8 updates up to and including 88** on this.

Slightly updated the issue summary I think we need to make the 9.x change first, and should probably leave all 8.x updates in 8.9.x just to avoid creating unnecessary work for ourselves.

should probably leave all 8.x updates in 8.9.x just to avoid creating unnecessary work for ourselves.

That's makes a tonne of sense.

I've updated the issue summary to match the current status quo of in-progress patches, copying here too and marking RTBC.

1. Updates from Drupal 8 to Drupal 9 must be from Drupal 8.8.x or Drupal 8.9.x, which will be the only supported versions when Drupal 9.0.0 is released. Sites on 8.7 or earlier must update to 8.8.x or later before then updating to Drupal 9. This will also encourage those sites to update contrib modules properly too. #3087644: Remove Drupal 8 updates up to and including 88**.

2. Add new upgrade path tests for updates added from 8.8 onwards, this has been done in #3089900: Drupal 8.8/8.9/9.0 update test coverage.

3. Leave older updates in 8.8/8.9 as-is, since removing them is likely to be more work than keeping them in for the next year or two.

Since this has been RTBC for a long time with no further comments, going to go ahead and mark fixed.

We're still working on the implementation of this but the plan is already being put into place in other issues.

Added a release notes snippet.

Fixed 9.9 to 8.9 in the release notes snippet. Also updated the relevant bits in the Drupal 9.0.0-alpha1 release notes draft.

Sorry to reopen this. I've had reservations about this for awhile but just was not able to focus on it until now.

I'd like to turn this into a policy discussion that will apply to future major releases. My comment in #17 was never addressed, which is the main reason I'm reopening this. However, I'm going to post the numerous concerns I have with the current plan for D8 here as well (rather than sidetracking the implementation issue).

1. For Drupal 8, I misunderstood the policy as proposed until just today (following discussion with catch). I did not think we would be deleting any update hooks numbered 88**. Drupal 8.7 has security coverage until the target release of 8.9/9.0, which means it seemed appropriate for me for folks on that supported release to be able to update from 8.7 to 9.0. Removing the update hooks from 8.8.x prior to 8.8.0 prevents that. It also means folks using 8.7 will have to upgrade twice in a row. That's not great UX.
    

2. Even when I thought the proposal was to remove update hooks numbered 87** and earlier, I had it in the back of my head that we might want to stretch it out since 8.7 was such a disruptive minor update. A majority of the outstanding upgrade path criticals are from the 8.6 to 8.7 update and some might require fixing some of those update hooks. So I've mixed feelings about the 43,000 sites still on 8.6. On the one hand, they're not supported as of Dec. 4; on the other hand, it's potentially our fault that many of them still can't upgrade.
    

3. An additional concern I have is the path alias upgrade path, which so far is not quite as bad as the 8.7 data model, but we're still getting difficult-to-reproduce reports of people not being able to update, so I'm still concerned we need to fix that (pre-8.8.0) update hook.
    

4. According to @catch, the plan is now actually to require folks to update to 8.8.2 (not a generic 8.8.x release) if they're using Workspaces. That's difficult to message and inconsistent with our messaging that 8.8.0 was the end of disruptions and incompatibilities in the 8.x series.

   @catch pointed out that 73,000 sites are on 8.8.1 vs. only 8,000 on 8.8.0 (about 10%), but OTOH I think that's not really the stat we should use:

   • People on 8.8 are already the early adopters, who were paying attention around then because 8.8.0 had only just come out.
   • 8.8.1 was a security release that included several SAs, one of which was critical, and several of which affected a broad range of sites.
   • 21,000 sites are on 8.7.11, the equivalent security release backported to 8.7. That's nearly 1/4 of supported sites. We can expect that to gradually go down over time, but we do know that security releases are the main drivers for sites updating.
   • Even if we have another security release between 8.8.2 and the release of 8.9.0, there will continue to be a significant portion of Drupal users on the 8.7.x equivalent.

    

5. We've done a bunch of work on the Update module and Drupal.org to allow things to be compatible with 8.x and 9.x at the same time, including work on how the upgrade status report presents 9.0. 8.7.7 was the threshold for those backports so that 8.7 sites would be more likely to see the changes. I don't think we've taken into account how the upgrade status report presents 9.0, but I feel like this is a complicating factor for that. It's also too late to improve the upgrade status report for those 8.8.1-and-earlier sites. I think we need to look at how 9.0's presented for such sites, file an issue to maybe add some messaging about which release is required to upgrade, and consider backporting those changes to an 8.7 patch release as a policy exception (before another security release comes out against 8.7, in order for it to be effective.)

I still need to read the implementation issue and there's a good chance the many pros of removing those hooks outweigh the cons (the more update hooks we have, the worse and more complicated upgrade path bugs become), but OTOH I'm concerned that much of the motivation is "technical debt; burn it down!" without taking into account the negative downsides for UX, the ecosystem, and sites taking advantage of the extended security coverage.

Circling back to my proposal for the future policy. Drupal 8 will have a support lifetime of six years. The very best case scenario for Drupal 9, on the other hand, is three and a half years, and we're likely going to need to release Drupal 10.0.0 at most six months after 8.9.x is EOL. Given that there will presumably be half as much technical debt and deprecations, and given the concept of the continuous upgrade path, I think we should consider retaining 9001 and higher update hooks in Drupal 10, and dropping them in Drupal 11. (I'm not sure about whichever 88** update hooks we end up retaining.)

#1. For sites that are on 8.7 or earlier, they should ideally update all of their contributed modules to the latest possible releases before updating to Drupal 9. Some contrib modules will no-longer be compatible with 8.7 at this point so it is safer to also update to 8.8 first while doing that. Updating core + contrib in 'one big hit' to Drupal 9 would theoretically work but in practice is going to be the most risky way.

Also 8.7->8.8 updates (and especially post updates) may be relying on backwards compatibility layers that we need to remove in 9.0.x

#2. The sites stuck on 8.6 absolutely will want to go to 8.8 or 8.9 first so that they can update contrib (of course they will also want to completely skip over 8.7 so that they can run the fixed updates instead of the broken ones).

#3. We don't have any critical path alias upgrade path issues at the moment, does something need to be bumped? However we can continue fixing upgrade paths in 8.8 and 8.9 once they're removed from 9.0.x for the next 18 months. Also in cases like #2998103: dblog_update_8600() breaks views.view.watchdog config entity, leading to PHP warning on admin/reports/dblog and configuration import errors where an older update runs successfully but leaves some 'wrong' data, if/when we add a new update to fix that data, those updates can and should be added to 9.0.x, 8.9.x and 8.8.x (and should be tested against an 8.8 database dump with the incorrect data).

#4. Posted a proposal so that we can defer the workspaces update decision a bit longer at #3087644-133: Remove Drupal 8 updates up to and including 88**.

#5. An issue I opened ages ago (not sure if I can find it again) was marking older unsupported core branches (i.e <= 8.6) as unsupported on Drupal.org. That might help indicate to people they need to get on a supported branch before doing anything else but it's a bit nuclear (and was rejected for that reason at the time).

without taking into account the negative downsides for UX, the ecosystem, and sites taking advantage of the extended security coverage.

In general I think a reliable, consistent, bug-free-as-possible upgrade path needs to override convenience for people on very old releases. People may get annoyed by being told they need to update to 8.8 first if they try to skip from 8.5 to 9.0, but what annoys people far more than that is fatal errors and lost data. So a message, linking to documentation, telling people that they're upgrading incorrectly and how to do it instead, while leaving their database in one piece, is a lot more friendly than letting them go ahead and getting a nasty surprise afterwards.

I think we should consider retaining 9001 and higher update hooks in Drupal 10, and dropping them in Drupal 11.

I'd be very concerned about doing this. Increasingly we're adding post update hooks which just load and save a load of config entities, and the actual update logic is contained in hook_ENTITY_presave(). This means we'd have to not only retain those post updates, but also the backwards compatibility layers in runtime code for an additional major release cycle. hook_update_N() may also require deprecated code that is being removed from 10.0.x, and it encourages people to jump from 9.0.x to 10.0.x without updating their contributed modules as far as possible first. Over time, as the number of updates accumulate, the more chance that two updates that would have been fine running in isolation conflict in some way, especially once you add contrib modules.

Thanks @catch for writing all that up in detail. Based on those answers, I think what's most critically missing right now is:

1. Issues like #3098475: Add more strict checking of hook_update_last_removed() and better explanation and an additional issue I think we might need for the update status report itself need to be backported as far as possible (I'm talking 8.7) so that we can give as many sites as possible the "right" instructions. I like the idea of linking the upgrade guide that will include our info about this from the messages they'll see in the Drupal UI as well.
    

2. Good point about the 8.6 update -- our message for them should be "Don't try for D9 yet; update to 8.8 when you can. We're still trying to fix the bugs affecting you." We need to incorporate this into our D9 upgrade docs.

   If we're going to encourage them to skip 8.7 altogether, does that mean we should be giving them security releases? I think we have a choice between either making patch releases for 8.7 that backport our upgrade path fixes, versus creating 8.6.x security releases for those old versions. We didn't for 8.8.1, but we still could provide it as a backport if we chose.
    

3. We have some docs gate work to do in the Drupal.org handbook on updating from Drupal 8 to 9 as well. The messaging needs to include reinforcing the information that if they're having trouble with the 8.7 or 8.8 updates, it's best to stay on Drupal 8 for now, and remind them about the security coverage dates for 8.8 and 8.9. I'm willing to defer it from commit-blocking on the first implementation issue (to uncork the deprecations) so long as it's blocking for the beta itself.
    

4. Let's make further investigation of the pathalias problems (or better user documentation about what not to do to not break the upgrade) a should-have. It's not as important as the actual reproducible ugprade path criticals unless we get to a reproducible problem we can fix.

#1. So specifically with #3098475: Add more strict checking of hook_update_last_removed() and better explanation, apart from possibly contrib modules removing old updates, won't affect 8.x core at all in practice, only when you actually update to 9.x - this is why we've only re-discovered that now, since the last time core implemented hook_update_last_removed() was for the 6-7 upgrade path...

I think I have a rough guess what you mean with update status and that's definitely worth an issue and backporting as far as we can.

#2. Yeah sounds about right - everyone should be aiming to get onto the most recent 8.8 patch release and the most recent patch releases of all their contrib modules, but this is especially important for people on Drupal <= 8.8

#3. +1.

#4. We actually made some progress today, the most likely culprit is #2917600: update_fix_compatibility() puts sites into unrecoverable state - several sites that ran into problems with the update had missing modules in the file system. That's now critical independently because the general bug causes data-loss, but will indirectly prevent the path alias issue from biting people (by forcing them to fix their missing module issues first).

If we're going to encourage them to skip 8.7 altogether, does that mean we should be giving them security releases? I think we have a choice between either making patch releases for 8.7 that backport our upgrade path fixes, versus creating 8.6.x security releases for those old versions.

Apart from the existing upgrade path bugs that aren't fixed in 8.8 yet (which only impact a small fraction of sites as far as we know), we can just tell people on 8.6 to update to 8.8 where upgrade path fixes are still being applied. There's no reason for people to update to 8.7 first even if we had zero upgrade path bugs.

Apart from the existing upgrade path bugs that aren't fixed in 8.8 yet (which only impact a small fraction of sites as far as we know), we can just tell people on 8.6 to update to 8.8 where upgrade path fixes are still being applied. There's no reason for people to update to 8.7 first even if we had zero upgrade path bugs.

Well, aside from @Berdir saying he would never want to skip two majors if he had the choice. And those 8.6 sites are critically insecure and there's 43,000 of them. So I'm wondering if we should have backported the last batch of SAs. Admittedly the usage data is always a few weeks behind so we might see a decent drop by next month, but OTOH we might not.

There's a further complication with backporting update fixes to 8.7 in that we could start to run into an 8.x equivalent to #3108658: Handling update path divergence between 11.x and 10.x - i.e. if we have to backport new updates to 8.7 that aren't sequential with other updates in 8.8/8.9 that we don't want to backport. So if we do want to backport anything, the security releases would be better than the updates.

I wish we had more data on how many people are actually stuck on 8.6 vs. there just being a higher install base than previous releases and therefore more people who haven't even tried to update yet.

Starting to wonder if we should try to adopt a one-on, one-off policy for adding updates similar to the 8.9->9.1 moratorium (at least for content entity updates). Something like any content entity updates have to go into 9.1, 9.3, 10.1, 10.3. This would make it easier to backport upgrade path fixes for longer then.

Tagging as a requirement for Drupal 9.0-beta1.

The last release blocking part of this is #3108416: Remove workspace_update_8803() which is independently a beta blocker.

We should keep this open against 9.x though so that we have a clear and predictable process for the 9.0.x-10.0.x transition.

For me I would probably keep it the same as what we've done in 8.8.x in terms of when we actually remove the updates - i.e. from the same release that does not introduce new deprecations so that contrib modules and database are all encouraged to move to a predictable point before the actual major upgrade.

The biggest obstacle to doing this properly has been the critical upgrade path bugs we've accumulated since 8.0.0.

One thing we could do is extend the moratorium on big entity schema updates that we added for 8.8/8.9 an additional release earlier. So essentially a full one year period prior to 10.0.0's release where we try to minimises schema changes. This ought to reduce the number of extant critical upgrade path bugs when the 10.0.x branch opens.

Before Symfony's release schedule was fixed, we'd planned to make fixing all the upgrade path bugs a condition of opening the branch, but support cycles forced us not to stick to that.

Tagging as beta blocker per @xjm in #3108254-17: [META] Drupal 8-9 upgrade path clean-up.

So I still think this issue is not actually beta blocking.

#3108254: [META] Drupal 8-9 upgrade path clean-up was opened to consolidate all the various database update system technical debt.

There are now docs at https://www.drupal.org/docs/9/how-to-prepare-your-drupal-7-or-8-site-for.... They can be fleshed out, but that's a documentation issue rather than a policy issue and we always needed those docs regardless of the specific policy decided here.

The Path alias issues we have diagnosed two different critical bugs, one is fixed, one is close.

We can't close this issue though, because we don't want to be having this discussion so close to Drupal 10.0.0's beta deadline whenever that is, but that makes it a Drupal 10 branch opening blocker not a Drupal 9 beta blocker.

Yeah I agree that this issue itself is no longer beta-blocking, but the implementation issues still are.

Moving to Drupal 10 (!).

Bumping this - it would be good to come to a decision here before it starts blocking Drupal 10 preparation.

The current situation is that apart from maybe a couple of post updates, we have not added a single hook_update_N() to Drupal 9 yet, meaning that potentially the first hook_update_N() will be added in 9.3.x or later.

This means that in terms of running updates, there are not going to be many to remove even if we remove everything prior to Drupal 9.4, unless we suddenly add loads to 9.3.x

However, I do think it still makes sense to require people to update to Drupal 9.4 before updating to Drupal 10, because that is going to be the safest way to ensure that contributed modules are updated too. i.e. the smoothest upgrade path is likely to happen in two stages:

1. Update core + contrib to the latest versions of everything on 9.4

2. Update core to 10.0.x or 10.1.x, potentially with a handful of contrib modules that have versions depending on >= 10.0

(replace 9.4 with whatever the last version of 9.x is).

vs.

1. Start with 9.0.x-9.3.x and update core and contrib to 10.0.x or 10.1.x all at the same time.

Bump.

We definitely don't have the same number of tricky updates in 9.x as we did in 8.x, however enforcing that people go to at least 9.3.x first, but ideally 9.4.x first, before updating to 10.x is still important IMO - massively narrows the range of things that can go wrong, and encourages also getting contrib updated first before trying.

One possible change here compared to 8.x is we may need people to update to 9.4.x prior to updating to 10.0.x in order for ckeditor5 to be available. If that's the case, we might want to remove updates all the way up to 93** in 10.0.x to enforce that step. However with ckeditor4 in contrib, I'm not sure this is the case, and a 9.3.x-10.0.x jump might still be allowable if not advised.

user_update_9301() is probably closest to the threshold here.

If we remove updates up to 9.4.0, we have to wait until 9.4.0 is released to do so (or remove some, then remove more later).

Since we don't have that many updates in 9.x in general compared to 8.x, I think I would just remove updates up to 9.3.0 at this point - i.e. the same pattern we followed for 8-9, and option 1 in the issue summary. We can still recommend updating to 9.4.0 before going to 10.x in documentation.

If we can agree to do that, we need to open an implementation issue.

I think that is good, unless we can identify one or more particilary tricky upgrade functions from 9.3 to 9.4 that would be harder to support in 10.x.

Yep. If for someone we did end up with one of those, we could always delete more later - but I think it makes sense to start the work now. Last time we did this, there was a lot of work renewing/reworking update path test coverage and database dumps etc.

I've opened #3261486: Remove core updates added prior to 9.3.0 and adjust test coverage. We can keep this open to discuss whether we want to force a 9.4.0 update, the main reason I can think of would be 'stable ckeditor', or for if there's any trouble with the <= 9.3.0 update removals.

#3285200: Importing older config without the mysql/pgsql module enabled will generate error only causes a problem when you don't update in the recommended way, but it also shows that a lot of people don't update in the recommended way.

So.. I think we should strongly consider removing 9.3-9.4 updates from 10.0.x too and require people to update from 9.4 or higher. Just after 9.4.0's release is good timing to do this since it'll be easy to find them.

Opened #3290810: Remove updates added prior to 9.4.0 (9.4.4 for ckeditor) and add 9.4.0 database dumps.

Bumping to the front as D10 releases this week.

We did #3290810: Remove updates added prior to 9.4.0 (9.4.4 for ckeditor) and add 9.4.0 database dumps so there is nothing left for Drupal 10 here.

"discuss what to do with \Drupal::CORE_MINIMUM_SCHEMA_VERSION" - that has its own issue at #3106712: Decide what to do with Drupal::CORE_MINIMUM_SCHEMA_VERSION and surrounding logic.

I think we probably need a new issue to track this for Drupal 10, but for me at least the policy issue is decided at this point - we always remove updates up until what is supposed to be the penultimate minor release, and then maybe further than that case-by-case.

Re-titling.

Quoting some discussion from #3401188: [policy] Remove update hooks added until 10.3 from Drupal 11.

Gábor Hojtsy

Now that Drupal 10 will be supported until the Drupal 12 is released, would it not be in line with that intent to keep the update functions instead? I understand that removing the upgrade functions is standard practice, but https://www.drupal.org/blog/drupal-10-will-be-supported-until-the-releas... would be counter to that?

@catch:

There are three reasons to remove older update functions:

1. To encourage sites to update contributed modules to 11.x-compatible versions before updating core to 11.x. i.e. sites on 10.3.x with updated contrib modules are much more likely to update to 11.0.x successfully than sites on 10.0.0 trying to jump all the way to 11.x and updating their contrib modules at the same time.

Sites on 10.0 may not be able to update contrib modules to 11.x compatible versions at all (if they rely on APIs added in 10.1 or 10.2), and they also may struggle to composer update contrib + core all the way from 10.0 to 11.0, because updating lots of composer dependencies at the same time gets very, very complicated.

2. To minimize the number of (core and contrib) update functions that can potentially have to run in the same update, for example if a site tried to update all the way from 10.0.0 to 11.6.0 (which would represent 4-5 years of core development) there could be tens of updates that need to run, config that gets updated multiple times for different changes etc. The more updates can potentially run, the more likely it is that we end up with dependency issues where update X has to run before update Y but after update Z and similar.

3. To reduce the matrix of update paths that we don't have test coverage for. e.g. ideally we'd have test coverage for 10.3-11.0, 10.4-11.0, 10.5-11.0, 10.3-11.1, 10.4-11.1, 10.5-11.1, 11.0-11.1 etc. but we don't have anything like that and can't add it with the current update test infrastructure.

I think that #1 is about the same with 10-11 as it was for 9-10. But #2 and #3 will actually be worse with two active branches, since we'll have more total minor releases to juggle, more updates paths to potentially backport between major versions (or not), and more potential paths to for people to take between different combinations of versions.

Or tl;dr, we've said that 10.x will be supported until Drupal 12.0, but we didn't say that Drupal 10.0 will be supported until 12.0.

fwiw I discussed #7 briefly with Gábor in slack and we realised that removing updates from 10.0-10.3 from 11.x doesn't preclude updating from Drupal >= 10.3 to 12.0.

That will depend on the functions added from 10.4/11.0 onwards and when those get removed. e.g. there could be a situation where you can update from 10.6 and 11.4 to 12.0, but not from 10.5 and 11.3. Or it could be that you can update only from 11.4+ to 12.0 - it all depends what gets backported to Drupal 10 minor releases, and what the cut-off point is. This doesn't automatically mean we'll support a Drupal 10-12 update path, but it adds an extra thing to think about in #2942096: [policy, no patch] Remove old update hooks prior to each major version (Drupal 10 and later) and is unaffected by this issue.

What this issue will do is prevent direct updates from Drupal 9.5-10.2 to Drupal 11.

I've updated the issue summary with a better explanation of why this happens, the pattern we've followed for 8-9, 9-10 and 10-11, and how this might look when we have 10/11/12 branches all open at the same time.

Since this is de-facto what we've been doing every major release, successfully, for several years now, going to go ahead and mark RTBC. We might want a new issue to track 10.x update backports from 11.x which is its own not small can of worms.

This change can be added to https://www.drupal.org/about/core/policies/core-change-policies/continuo...

Update functions added to the minor release that coincides with the first release window of the next major version are removed. After Drupal 11, this changes so that update functions added to the minor release that coincides with the major release are removed.

This issue has a change record, it doesn't seem to me that it is still needed?

I removed this issue from the change record, the CR is still valid for the other issues it was attached to.

For what it's worth, after seeing the D9 and D10 upgrade paths, I've come around to agreeing strongly with @catch's recommendation.

I also agree with tracking upgrade path backports; tagging for a followup for that. I guess it would be a child of the D12 meta tree which may also need creation still?

Removing the RM tag since we all agree on this.

I was going to open a new issue for the 11.x and 10.x update path co-ordination, then I thought I'd better reference #3108658: Handling update path divergence between 11.x and 10.x, then I realised nothing has changed. Have updated the issue summary there with the new major version numbers. Let's use that one.

I see how this improved our stability and made our life less complicated. I also think its a far fetched idea that Drupal 10.x users would update to 12.x in place, that would require all of their contribs to somehow support that update too. So we don't need to bend over backwards to support that. Let's consider this policy agreed and refine the update functions if/when we have feasibly backportable solutions.

Changing to latest version when this was closed.