I know that some library maintainers like @dbu like the weak_vendors mode because it freed them from bumping that number every once in a while, would be great to hear from them…

Or maybe even better: keep the current behavior as is, but handle setting the max numbers of deprecations triggered "inside src/" vs "directly by src/" vs "indirectly (by src/ or config/)".
Could be e.g. just numbers separated by commas, in the above order:
SYMFONY_DEPRECATIONS_HELPER=999,0,888
This meaning: 999 deprecations max, 0 triggered inside src/, and max 888 directly.

when maintaining a library, errors on vendors triggering deprecations of other vendors is not much of a concern. i want to support a wide range of dependencies if possible. those deprecations are the concern of the users of my library, but not mine as library maintainer.

i like the idea to be more precise. using comma separated will not make it more obvious what is going on (its quite cryptic already) but having 3 separate constants is not awesome either.

i was going to say we should not change the semantics of the old syntax in minor versions, but as the symfony bundle test configuration matrix usually specify which symfony version to test with, its easy to use a different constant definition for different configurations.

What about using an url-encoded string for configuration? Looks like the most flexible to me given the number of options people would like to have and we might want to add in the future.
E.g. SYMFONY_DEPRECATIONS_HELPER="max[total]=1234&max[direct]=10&max[internal]=0"

This sounds great! For the sake of completeness, I would have 4 keys:

SYMFONY_DEPRECATIONS_HELPER="max[total]=1234&max[indirect]=42&max[direct]=10&max[internal]=0"

This would mean:

• no more than 1234 deprecations in total
• no more than 42 deprecations where both the caller and the callee are in vendors
• no more than 10 deprecations where the caller is in src and the callee is in vendors
• no deprecations where both the caller and the callee are in src

And every key would default to 999999.
Would we get rid of the weak and strict modes too according to this plan? What about the SYMFONY_DEPRECATIONS_HELPER=42 mode? And what about the regex mode?

Correct! I'm just wondering if "direct" should count internal too? They are also "direct calls to deprecated methods". Or we could be keep only direct (would include internal) and indirect. WDYT ?

The regexp mode is absolutely required to debug deprecations, I'd keep it as is. The others we can think about simplifying. We could also have summary=0/1 (default to 1).

I have written #24867 so that when we use sentences that use the words "caller" or "callees", we refer to packages, not to methods. Any stack trace can be divided into function calls, and those calls can be grouped by package easily if psr-0 or 4 is assumed (I hope that's a safe assumption to make).

With that in mind, internal would have no notion of direct or indirect calls, because there would be no calls to external packages involved here (I'm overlooking the case where you have src -> vendor -> src, which I don't know yet how to handle properly).

Or we could be keep only direct (would include internal) and indirect. WDYT ?

I think @alexpott and other library maintainers would not want us to have direct include internal and make internal disappear.

Also, I have witnessed a use case in a project in my company where you would want to forbid direct calls but allow internal deprecations because of the following scenario, which happen to me:

1. remove something, and all references to it;
2. make a PR;
3. wait a long time because your reviewers are busy;
4. someone in another team merges a PR which introduces a new reference to the thing you removed;
5. your PR is finally merged;
6. 💥

Another scenario is that you could want to deprecate something internally in your project that is used in many places and migrate from it step by step, while keeping direct calls to 0.

A final argument against this would be that having direct include internal and not have indirect include direct and internal would be a bit disturbing. I would be one step close to have the nice total ⊂ indirect ⊂ direct ⊂ internal, somewhat frustrating.

Here is how existing modes would translate:

• strict: SYMFONY_DEPRECATIONS_HELPER="max[total]=0"
• weak_vendors: SYMFONY_DEPRECATIONS_HELPER="max[internal]=0"
• weak: SYMFONY_DEPRECATIONS_HELPER="max[any_valid_key]=999999"

I have written #24867 so that when we use sentences that use the words "caller" or "callees", we refer to packages, not to methods.

This decision can of course be challenged, especially in the light that some people like @lcobucci think it should be ok for a package to deprecate calls from outside, while expecting no error when calling something deprecated internally, see doctrine/orm#6728 (comment)

Nobody should be bothered if we're using internally our own deprecated items (this already happens with ClassMetadata and ClassMetadataInfo btw).