Defer disruptive 11.3 deprecations for removal until 13.0

The main difference between this and what we did for 10.x-11.x is that we'd start deferring disruptive deprecations one minor release earlier relative to the next major release window. Even though we'd start with 11.3.x and 10.3.x, we have an additional 11.x minor release before 12.0.0 comes out this time due to how the release windows worked out with 9.x/10.x/11.x- which makes this confusing to talk about.

If we start deferring deprecations with the 11.3.x cycle, it means that on the earliest day that 12.0.0 can be released (the June window), the following core branches would have security support:

12.0.x (june 2026)
11.4.x (june 2026)
11.3.x (december 2025)
10.6.x (december 2025, whether we actually branch or continue on 10.5.x is TBD)

The exact EOL date of 10.x is also TBD, but we have the option to commit forward-compatibility fixes to 10.6.x while 11.3.x is in development.

11.2.x security support comes to an end in that June window too, so if there are 11.2.x deprecations that a module needs to deal with, then it may need to drop 11.2.x support when adding 12.0.x support or have two code paths etc. If we miss the June window, then 11.2.x is fully out of the picture too.

This means that at least for straightforward modules, they may be able to support 10.6.x, 11.3.x and 12.0.x with a single branch or at least very minor divergence between minor branches.

We already have annotation and procedural hook deprecations for removal in 13.0.0, either in core or planned very soon, because we know that's going to require a lot of effort to update for, so this is consistent with delaying the removal of those by a major release.

It also means that there should be a finite amount of things to account for in phpstan/rector from June this year.

I think this is fine, we need to tell the community as soon as possible to give them time to do stuff they were planning quicker now as long as it is possible.

I also have no issue with this, marking NR to get any other feedback from the community.

Think it makes sense

If a deprecation is for base classes, interfaces, or otherwise likely to affect a lot of modules, deprecate for removal in 13.x

Sure there will be some learning curves so posting this somewhere may also help. Where I'm not sure as I still find the drupal docs hard to navigate/search.

Where would all the hook deprecations fall under?

Procedural hooks haven't been deprecated yet. Similarly we haven't deprecated annotation discovery in 📌 Triggering deprecations for plugins using annotations when core plugin type has been converted to attributes Needs work either, I don't think either of those will happen for 11.2, so the earliest they could land is 11.3.

However, although I can't immediately find it, we'd already discussed deferring both of those deprecations for removal in Drupal 13 anyway.

For annotations, there are all of the plugin annotations to convert, but also all the plugin managers need to support attributes before that can happen. So for contrib modules that implement plugins for other contrib modules, there will be chains of 2-3 issues to get it all done. Deferring removal of that to Drupal 13 gives a solid three years for all of that to filter through.

Procedural hooks as a whole I think we would definitely defer removal to Drupal 13 - it's going to affect almost every single contrib and custom module.

But specific hooks like hook_module_implements_alter() we'd probably still remove in Drupal 12 because they have tricky bc layers to deal with, especially if it makes other conversions and clean-up easier to do in Drupal 12.