- 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
This reminds me of PHPUnit's soft deprecation 🆚 hard deprecation: https://phpunit.de/backward-compatibility.html#soft-deprecation 🆚 https://phpunit.de/backward-compatibility.html#hard-deprecation
- 🇬🇧United Kingdom catch
We could consider switching any deprecations that we're leaving in from @trigger_error() to trigger_error() (unsilenced) when we open the new branch.
From experience, this would have helped with entity query ::accessCheck() where neither phpstan nor test coverage has caught everything and some contrib modules have released Drupal 10 'compatible' versions with exceptions due to that change. If we'd gone from @trigger_error() to an unsilenced deprecation instead of straight to a warning we might have caught more of these before the exception started getting thrown.
- 🇬🇧United Kingdom catch
This came up again in 📌 Remove deprecation about Views argument config conversion from numeric to entity_target_id from 10.3.x Closed: duplicate , we might have more options now we're on gitlab. It's also going to become more important with longer major branch lifetimes.
Re-titling because this is really about contrib testing being able to ignore deprecations that are removed in much later versions.
For core, we want all deprecations to trigger errors all the time, so that we don't deprecate something we can't remove yet, except for very rare cases (a class implementing a deprecated interface for bc or similar) which we would skip individually.
For contrib, the default case is usually going to be that until 11.0.0 is released, you want to ignore deprecations for removal in 12.0.0 - especially when the replacement is not in all supported branches back to 10.1 or 10.2.
But then, at some point after 11.0.0 is released and 10.1/10.2 are out of support, you would want to get notified about deprecations for removal in 12.0.0, and not get notified about deprecations for removal in 13.0.0.
