Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64002
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.219.42 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAAyV7nF3VyvCa_YCYrtaajm8b8CpTCUq7M6=07hJ5eCGBaUZrA@mail.gmail.com>
References: <CADajX4CYZdNpgQv46m_6J7tQLBc=h6HxCn-bGpxr3Ou2VaqgBg@mail.gmail.com>
 <CACwt+JeLin8aLtmBedO+DnJ4cz0Ajb75depkd7v_QK1NORUPOg@mail.gmail.com>
 <CADajX4CmOEBy3aZOh+qpfmq=OTiLF6+EuOyiRWM2bx7JxZumrg@mail.gmail.com>
 <50A9F799.5080909@codeangel.org> <CADajX4CbLLagJnO+dkZsGXkaS8h7rabtmpOz6Gos0KqcHOpsMA@mail.gmail.com>
 <CAAyV7nF3VyvCa_YCYrtaajm8b8CpTCUq7M6=07hJ5eCGBaUZrA@mail.gmail.com>
Date: Wed, 21 Nov 2012 12:47:25 +0800
Message-ID: <CADajX4AxoK73x-CoJx71j6g3ndiMbF2LYhnLrs2p_CcOBxmgjQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
From: aharvey@php.net (Adam Harvey)

On 19 November 2012 20:44, Anthony Ferrara <ircmaxell@gmail.com> wrote:
>> My intention at this stage is to call a vote next Monday: it feels
>> like the discussion has mostly died down now (which isn't to say I
>> think we're at a consensus necessarily =E2=80=94 it just feels as though=
 the
>> flurry of opinions have been made and argued either way), and I'm
>> hoping that everyone can have a think about where and how they'd like
>> to see this move forward (if at all) between now and then. Given we've
>> only just hit alpha 1, I don't think we need to rush into a decision
>> right now for the sake of one.
>
>
> I completely agree.
>
> I would suggest one thing though. When it comes up for a vote, please eit=
her
> make 2 questions:
>
> 1. Should ext/mysql be hard-deprecated in 5.5
> 2. Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT
>
> Or 4 options to deprecation:
>
> 1. Hard-deprecated in 5.5
> 2. Soft-deprecated in 5.5 and hard-deprecated in NEXT
> 3. Either
> 4. Neither
>
> That way both viewpoints can be voted on in one vote. And we can get an
> accurate count of the thoughts...

I've been mulling this for a couple of days, and Anthony and I have
talked about this on IRC, and I'd prefer to have two questions:

1. Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no)

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 entirel=
y

The reason for this is that I'd like to make the vote about the actual
RFC (E_DEPRECATED in 5.5) as clear as possible. I'm worried that a 3
or 4 option vote there could easily lead to a split decision, which
will make it very difficult to take any sort of decisive action. I'd
rather make a decision there, then we can look at what action would be
preferred if the RFC itself fails.

Just to be clear: I don't think that "do nothing" is a very useful
option for the second question, which is why I've omitted it =E2=80=94 it
doesn't seem like anyone's particularly satisfied with the current
state of affairs.

Thoughts?

Adam