[policy, no patch] Target any 11.x API/disruptive deprecations for removal in 13.x

In regards to 'impact' a good way to at least see true usage in contrib we can user this search, which is pretty good at cleaning false positives:

https://git.drupalcode.org/search?group_id=2&scope=blobs&search=-path%3A...

Other than that I do think we should indeed be very weary of impact of deprecations. Considering core maintainance versus community impact.

Possibly relevant ✨ Tooling for code upgrades topic, core gate, and maintainers Active .

Can you post the actual search field query, I think your url is getting truncated. Incidentally I was looking for ways to check contrib usage and found the gitlab search to be a bit inconsistent. There is an issue to change the search backend for code search that will vastly improve it.

Clicking on the URL itself worked for me.

Will repost, click indeed seems to have a ... in the center of the filter.

Thanks @bbrala, that seems to work so much better than the searches I was doing!

Just a couple of notes on limitations of that search I see still for others using it.

1. It excludes distributions that include all of core as part of their project (probably fine since technically the distro isn't using the code technically and will get the changes when they update, also committing core isn't technically supported.
2. It does not seem to properly handle yml keys and does some fuzzing even with quotes. e.g. search "country.default" instead of EntityReferenceTestTrait and you'll get a lot of false positives.

I'll be using this in the future though for sure.

I have been thinking about this since I first read the Slack discussion. Assuming I can count correctly, this would allow a minimum of 2 years for contrib to update for disruptive changes. That alone provides some stability and allows contrib maintainers more flexibility in when planning their upgrades. I think that is a very useful.

The proposed solution is clear and easy to implement. The part that will require discussion in the issue is to determine if the change is disruptive. Fortunately, there is already a definition of disruptive changes → in the policy docs. And @bbrala has supplied a link to help with the search. (Thanks @bbrala!) When this is resolved that information should be included in the continuous upgrades policy .