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.

Since there's been no further feedback at needs review, let's see if there's more feedback at RTBC.

📌 [Plan] Determine how to deprecate procedural hooks. Active is where we discussed procedural hook deprecation.

If I am being honest I'm not sure I see how we can directly deprecate procedural hooks, it will more likely be a side effect of deprecating .module files. There just isn't a clean way to know whether a function is a hook or not. We can throw a message runtime in LegacyHook, but that seems riskier than we would want to be.

Side note, hook_module_implements_alter and hook_hook_info are also strange deprecations because we are just removing them in 12.

So essentially you get 1 to 1,5 year to adjust to internal deprecations and 3 to 3,5 years for public API deprecations as of 10.3?

The latter seems a bit on the high end if you ask me, but I agree that an absolute minimum of 1 year is too short for contrib and client projects to adapt to disruptive changes. Ideally, we have a 2-year window as a hard cut-off, but trying to align that with major core release dates is tricky.

Essentially you'd have to deprecate things right out the gate when a new major release is cut, which seems impossible unless you postponed deprecations from the last major. And that would essentially be the same deprecating over 2-4 years, but with extra steps.

So with that in mind I suppose RTBC +1, even though I'm not fully a fan of keeping dead weight around for more than 3 years.

If I am being honest I'm not sure I see how we can directly deprecate procedural hooks, it will more likely be a side effect of deprecating .module files.

Yeah that might be the case. In terms of this issue, we could still deprecate them in any minor version of 11.x, it's just that removal of support would be deferred until 13.0.0

@kristiaanvandeneynde yes it would be 3-3.5 years, although hopefully 3.

Essentially you'd have to deprecate things right out the gate when a new major release is cut, which seems impossible unless you postponed deprecations from the last major. And that would essentially be the same deprecating over 2-4 years, but with extra steps.

Yeah this is what we did with some issues from 8-9 and... exactly.

It wouldn't be only @internal deprecations for removal in Drupal 12, we might decide to deprecate some other things for removal in 12.0.0 if they're low impact on contrib and will cause problems to keep around in core, but the default would be that yes.

+1 from me too