#1176 Deprecate (Blacklist|WellKnown) schema filters

[ostrolucky]

No description provided.

[nicolas-grekas]

Should we unregister the pass in DoctrineBundle?
I don't think it provides many benefits now, isn't it?

[ostrolucky]

In linked issue @greg0ire pointed out this is still being used by eg. Lock component. Is that no longer the case and there is no longer any reliance from Symfony on these? If no, only then I'm ok to unregister the pass.

[nicolas-grekas]

/cc @weaverryan any input?

[ostrolucky]

Alright, enough time passed. I even pinged @weaverryan on Slack. Merging.

[weaverryan]

Sorry for not being on time. Here's the related PR: symfony/symfony#36655

So Messenger & Cache is no longer needed. For Lock & Session, those still need more work. We should really implement those correctly (so that they can be fully removed here)... but it's not done yet.

Btw, in this PR, we deprecate WellKnownSchemaFilterPass. Will this trigger deprecations in all projects since it's still being used in DoctrineBundle? And if I do see this deprecation, how should I update my code to remove it?

Thanks!

[ostrolucky]

Btw, in this PR, we deprecate WellKnownSchemaFilterPass. Will this trigger deprecations in all projects since it's still being used in DoctrineBundle? And if I do see this deprecation, how should I update my code to remove it?

I don't know. But if it does, I don't see how can we fix this here in doctrine-bundle. We need to mark those classes as deprecated, but at the same time we should internally keep compiler pass registered for BC. In such case I think it would be best if symfony didn't report such deprecations, only if users outside of this bundle are instantiating deprecated compiler pass class.

[nicolas-grekas]

Symfony won't report it because there is no runtime deprecation. A static analyzer will of course.