Remove deprecation about Views argument config conversion from numeric to entity_target_id from 10.3.x

MR is up and green.

Thanks for the detailed right up.

Change looks straightforward and didn't break anything so don't mind marking.

Per the slack thread this needs more discussion still.

I’m okay to keep discussing, but 10.3.0-rc1 is out, so we have very little time to get this done if it’s going to matter at all. 😅

To me, it boils down to the costs of leaving it in (hardship for maintainers that like to “chase HEAD”) vs the costs of removing it (none, other than the time to discuss it). 😉

The primary argument from Berdir against this is basically “chasing HEAD is a fruitless, pointless effort that only leads to more work and suffering”. I pretty much agree with that, and don’t do it myself. 😂 But some maintainers like to do it, anyway, and by one perspective, they’re trying to do the right thing by staying on top of core development that impacts their code.

As I wrote in the summary, the perspective I do hold is that, when feasible (or in this case, trivial) to make it easier for contrib to put out releases that are as widely compatible as possible, we should.

Not sure who else needs to chime in before a decision is made. I only hope it happens soon. 🙏

Thanks,
-Derek

based on what I've seen on majority of contrib modules most maintainers aren't doing that haha. Some of them just jump in every few months sometimes, which is fine. So whatever can be done to help them out +1 from me.

Maybe we can use the SYMFONY_DEPRECATIONS_HELPER variable to ignore that specific deprecation or set it to some value that allows the test to pass. See https://symfony.com/doc/current/components/phpunit_bridge.html#making-te...

I'm not sure we should not be making this change. We should make our tooling support this. I tend to disable deprecation reporting in CI use deprecation reporting when I run the tests locally or when I’m prepping to change update the minimum supported version.

Given we have the drupal version in the deprecation message we should extend SYMFONY_DEPRECATIONS_HELPER to take a value like drupal-verion=10.2.x and then skip deprecations from 10.3.x and above.

Yeah I agree it's a real problem but to do this all the time we'd end up needing three MRs for every similar issue (Drupal 11, no deprecation or bc layer, Drupal 10.4 deprecation + bc layer, Drupal 10.3, bc layer and no deprecation).

Linking #3225792: Allow core deprecation testing to distinguish between major versions → , also wondering if we should move this to gitlab templates or open a new issue there? It would be nifty to be able to do this generically.

Since this seems to be like something that needs to land in 10.3 or not be needed could we move forward here and open a follow up for more discussion?

I think we should continue in #3225792: Allow core deprecation testing to distinguish between major versions → , going to retitle that one, closing this as duplicate.