👍 had numerous deprecated warnings after upgrading to 2.7 and this PR solved all of them.

The deprecation warnings are triggered intentionally to let you know what you need to change in your code to be forward compatible with Symfony 3.0.

Youcould silence them by changing your project'serror_reporting level, but I'd rather update your code.

This PR may be a good idea in fact don't you think?

The most profound PR I've ever seen. A must merge. 👍

@nicolas-grekas Not sure if I understand. Which issue would this change actually solve?

It switches deprecation notices from opt-out to opt-in

Yeah, but is that really a good idea? I bet that many people then will never know about this and that they will be surprised when their apps break on Symfony 3.0. Not sure if that's a good experience either.

I think it is a good idea.@deprecated tags are sufficient, but calling trigger_error() is very shouty.

Googling most of the deprecated errors that come out result in most cases with the people discussing end suggesting and / or agreeing that muting E_DEPRECATED in php.ini is the best solution.

If the intent is to get people to prepare for 3.0 then, well people aren't. Instead they are just muting the warnings. Further more, for upgraders, seeing the messages for the first time, diagnosing / solving them the correct way is very difficult as google has little to offer in the way of answers.

Perhaps some of the deprecated calls don't actually have future ready implementations in place yet. I believe this was the case with the Form components OptionResolverInterface, which my IDE informs me was deprecated in (I think it was) 2.5 or so, but no alternative was provided until something like 2.6 (with OptionResolver).

Still thinking about it, I really like the idea.
Upgrading to 3.0 is also an opt in, the upgrade path is clear.

I'm 👍
Reopening to see what other @symfony/deciders think

@reecefowell can you please enhance the commit message?

@nicolas-grekas are these deprecation warnings still reported in the logs after being muted or no ?

And does the silencing add some overhead or no ?

ping @symfony/deciders

If we agree on this one, I'd like to merge ASAP for at least two reasons:

• I want to release 2.7.1 ASAP
• Maintaining such a large patch is going to be difficult over time.

So this only changes that the deprecation warnings are ignored in production, or?

Yes, by default

So how would I turn on deprecation notices now?

By adding a user land error handler, like the one provided by e.g. the debug component

Comments addressed in code, also tests are now passing. Somehow though I seem to have broken fabbot.io.

The patch just gave me this

curl http://fabbot.io/patch/symfony/symfony/14900/eb261d45b038f9af47a92b4e6b602bcf8a853816/cs.diff | patch -p0  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed100  8717  100  8717    0     0  20591      0 --:--:-- --:--:-- --:--:-- 20607patch: **** Only garbage was found in the patch input.

So I applied the changes manually, but I guess maybe because I pushed another fix while fabbot.io was still running it broke it this time around.

Fabbot.io was talking about code I never touched though. So I guess those problems were already there.

Apparently the patch only contains garbage.... 😕

Other than that. Good to go.

To summarize a few questions people had (that I also had):

A) Do you still get deprecated warnings in the web debug toolbar? YES

B) Do deprecation warnings still show up in the logs? NO

Does this have any other side effects?

If there are no other side effects, I'm +1. We can add something to the "how to get rid of deprecation warnings" section of the docs to show people how to hook up an error handler to log the deprecation warnings.

Ready to be merged?

Nice! Thanks for the clarification@nicolas-grekas.

Would it not be better to change the production error handler instead to not log by default if that is what we want? Triggering deprecations and at the same time silence them seems like a hack.

@Tobion this PR solves a real issue/pain users experiment with 2.7.: they must opt-out from deprecation notices. If we think this is required then we should not merge this PR.
If we think the deprecations should be opt-in, as would be migrating 3.0, then this PR is the right one.
Nobody but me voted here. Please do @symfony/deciders

@reecefowell please rebase

I agree that this should have been opt-in rather than opt-out. I do not know if there is a more elegant approach as I agree with@Tobion it seems hacky to use@trigger_error().

I understand how you can see this as a hack. There is an other consideration that makes me think this is really the best: performance. We could wrap the implementation of triggering "opt-in deprecation notices" behind some more semantic interface. But that would add overhead to something that needs to be as fast as possible. This is not a micro-optim when this can be called thousands of times.
Thus this raw-bare-metal-php implementation that may look hacky, but is just the right implementation for our needs. At least that's my humble opinion :)

I'm going to merge this today if nobody vote otherwise.

👍 as I see people struggling with deprecation messages, especially in cli. However, we should provide clear instructions on how to enable them.

👍

It also means we are much less intrusive for other libraries relying on Symfony 2.x

👍

I am still not fully convinced. How would people now see the stack trace for a triggered deprecation if it is not contained in the logs? The debug toolbar doesn't provide one.

Thank you@reecefowell

@xabbuh we still have to work on better deprecations reporting.
But at least, we can do it quietly now, without hurting users.

Thanks everyone :)

Are bundle developers encouraged to do this as well?

@craue I'd say yes!

👍 Good move :)