Conversation
|
I have updated 5d20e3c for the |
|
doctrine/deprecations#4 doesn't look like a proper solution to the problem. It shouldn't be necessary for a library to suppress its own calls to its own deprecated APIs. In fact, not calling a certain method because it's deprecated may be a BC break on its own because somebody may have extended/implemented this method, and their extension is no longer effective. So not reporting deprecated calls within the library should be the default behavior. |
morozov
left a comment
There was a problem hiding this comment.
i went over each call again and converted quite a few back to using
trigger.
That's quite a few but I think we can do better. Please see the comments.
|
Failure is fixed in deprecatios 0.5.3 but i cannot retrigger the appveyor build. |
morozov
left a comment
There was a problem hiding this comment.
Failure is fixed in deprecatios 0.5.3 but i cannot retrigger the appveyor build.
It warrants a bump of the Deprecations version.
Looks good! Just needs the changes in the last few commits moved under the corresponding original commits.
…iresQueryForServerVersion
…ect/groupBy/addGroupBy with array argument.
Turns all the possible deprecated APIs into using the doctrine/deprecations API.
This includes deprecations on everything that can be done with code at runtime and is missing only the deprecation of
fetchmethods on theStatementclass, which need this PR #4529 for forwards compatibility to suggest a migration fromStatement::fetch*toConnection::executeQuery->fetch*()