Re: RFC: ext/mysql deprecation

On 21/11/12 16:08, Adam Harvey wrote:

On 21 November 2012 13:03, David Muir <davidkmuir@gmail.com> wrote:

On 21/11/12 15:47, Adam Harvey wrote:

2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what should the next course of action be:

    (a) Enhance the manual text to make the soft deprecation clearer,

and generate E_DEPRECATED notices in PHP 5.6

    (b) Enhance the manual text to make the soft deprecation clearer,

but take no further action in terms of E_DEPRECATED for the forseeable future

    (c) Remove the warnings from the manual and undeprecate ext/mysql

entirely

Has 2(c) been even suggested?

Not that I've seen, but having a "none of the above, I want none of this" option seems prudent.

Except it's "lets reverse the changes already made", not "none of the above".

I take at that 2(b) is for those advocating "Move to PECL with no E_DEPRECATED notices being thrown"?

Not really. We can't really unbundle and move to PECL without deprecating first anyway, IMO. It's basically the option for no real change but clarifying the manual wording, since nobody seems satisfied with it.

No other extension was deprecated before moving to PECL, so why the extra hurt for ext/mysql? As I've said before, it doesn't makes sense to have it throw notices while it's in core, then no longer throw notices once moved to PECL. If the plan is to drop it completely, and not move it to PECL, then deprecation notices do make sense as there's no other recourse once the extension is removed. In that case we really should have 3 questions: Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no) Should ext/mysql be moved to PECL or dropped completely in the future (PECL/dropped) Should the manual text be changed to make soft deprecation clearer? (yes/no)

Or, to put it another way from where I sit: the "too hard, let's make a decision after stringing people along longer" option. Adam

Cheers, David