Let's use a specific example to try to understand the different modes:

• ACME App depends on two third-party bundles called FooBundle and BarBundle
• Deprecation 1: ACME App has a controller extending from the deprecated base Controller. This controller is created and used by the app. Code doesn't belong to any third-party bundle.
• Deprecation 2: FooBundle provides a Form extension which doesn't include the new public static function getExtendedTypes() method. ACME App uses that form extension directly in its code.
• Deprecation 3: BarBundle includes a Twig template with the deprecated transchoice filter. ACME App DOESN'T use that Twig template anywhere in its own code or config.

@greg0ire please, fill in the following descriptions:

• _________ mode shows deprecation 1) only
• _________ mode shows deprecations 1) and 2)
• _________ mode shows deprecations 1), 2) and 3)
• Using an integer as the deprecation mode is a special behaviour. It behaves as the __________ mode but only triggers an error if the total number of deprecations is higher than the provided number.

Thanks!

Hey @javiereguiluz ! Thanks for your review!

I'm going to have a hard time filling the blanks though, for several reasons. For starters, modes rarely change the output a lot, and they will not hide one type of deprecations over the other. The only mode that changes the output a lot is the weak mode, because it does not show a detailed output of the deprecations, only a summary. Modes are mostly about the exit code, rather than the output. Second, none of your examples show deprecations where both the calling code and the deprecated code are in src, and this is what weak_vendors is all about. You are using an application as an example, but it will be hard to find a valid use case for that mode inside an application, it is more useful for libraries.

So, let's take the example of a library Foo, that depends on another Bar library. Inside Foo\deprecated_function, you can find a call to @trigger_error('some message', E_USER_DEPRECATED); but, and this is key, you cannot find a call to Foo\deprecated_function() in Foo's src directory, because the person who deprecated Foo\deprecated_function() changed all the calls to Foo\shiny_new_function(). Inside that src directory, you can find a call to Bar\deprecated_function(), which is part of the deprecated API of Bar.

1. strict mode will let the build exit with a non-zero exit code. 💥
2. weak_vendors mode will let the build exit with a zero exit code. 👍
3. weak mode will let the build exit with a zero exit code. 👍

Now let's say the contributor forgets one call to Foo\deprecated_function() somewhere in Foo

1. strict mode will let the build exit with a non-zero exit code. 💥
2. weak_vendors mode will let the build exit with a non-zero exit code. 💥
3. weak mode will let the build exit with a zero exit code. 👍

What's next?

symfony/symfony#28048, implemented in symfony/symfony#29211 and documented in #10701 is a big revamp of all this, and will introduce a way for an application to only care about deprecation that can be fixed directly within itself, meaning they will be able to call Foo even if Foo calls Bar\deprecated_function().

I'm closing this since I deprecated the weak_vendors mode recently.