Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71230
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAL+t6cFL-vtpB5b26_jDcXmC36aT9ZXpRUvNGDSi-5J4f7sRVg@mail.gmail.com>
References: <CAMUwpuSoK9BmchwCx88QXicKmwJ9AmzRkwwMqXsrpSjkukCkRg@mail.gmail.com>
 <CAL0xaBGUv5vsQUO1ZLq-uYT_8goWB8pKTMukk7vnWZRwcD7R=w@mail.gmail.com> <CAL+t6cFL-vtpB5b26_jDcXmC36aT9ZXpRUvNGDSi-5J4f7sRVg@mail.gmail.com>
Date: Sat, 18 Jan 2014 03:42:10 +0100
Message-ID: <CAMUwpuQNC8UO=Yw-iHXqLV68LQwj0bOhBuNQt-YkQd6up-1QJQ@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] 5.5 to 5.6 cleanup
From: jpauli@php.net (Julien Pauli)

On Sat, Jan 18, 2014 at 2:55 AM, Sherif Ramadan <theanomaly.is@gmail.com> wrote:
> On Fri, Jan 17, 2014 at 8:35 PM, Arvids Godjuks <arvids.godjuks@gmail.com>wrote:
>
>>
>> As it was mentioned, it was not decided that mysql ext should be completly
>> removed at 5.6, my personal opinion is that it should be pushed po PECL at
>> this release with all the bells and whistells warning everyone that
>> extension is depricated and will be removed soon (read: next release - be
>> it 5.7 or 6.0).
>
>
> The plan was always to move ext/mysql to PECL. We've never removed an
> entire extension from the source completely without it going to PECL (as in
> the case of SQLite).

For sure, we don't delete code from our codebase.
We don't drop ext/mysql code , we clearly move it to PECL, yes.

> Which is why the decision was made to first update the
> documentation warning people that ext/mysql would soon be deprecated. Later
> the decision was made to start issuing E_DEPRECATED errors in PHP 5.5, as
> per the aforementioned RFC that was accepted. This has all been done
> already. The next step is to remove ext/mysql from PHP core and place into
> PECL. The various linux distributions will likely still package it
> separately as they already do with other various PHP extensions. So this
> will not likely affect those who rely on using their distribution's package
> manager to install PHP extensions. However, that is not to say that we
> should spring things upon users suddenly and without taking the necessary
> steps to ensure a smoother transition.

For me that's clear.
- We added E_DEPRECATED at runtime
- We updated docs to reflect that

We'll still provide the code to a PECL ext, and linux distros will
package it, so no pain for anyone wanting to use ext/mysql once it's
moved to PECL.

>
>
>> I belive that leaving everything as is right now will be
>> sending a message that projects like Wordpress can halt the progress of the
>> language development and block the decisions like removal of the mysql ext.
>>
>>
> I agree that we should not be waiting on Wordpress to update their code in
> order to make the decision of removing ext/mysql. In fact, in our previous
> discussion back in 2012, Wordpress claims they were the ones waiting on us
> before they updated their code http://news.php.net/php.internals/63929
>
> We've given fair warning that the extension will be removed soon. I'm just
> saying that the decisions to remove it was never finalized to 5.6. We've
> ramped-up our release cycles and we've gone from 5.4 to 5.5 to 5.6 in less
> than 2 years now.

Yes, we don't have to wait for anybody to take actions.
We should be driving projects using PHP, not the opposite (which
doesn't mean we should not listen to everybody and take selfish
decisions).

If we go to remove it in 5.6, anyway, we all know there will be a huge
time before 5.6 enters to production, years...
Also, nobody can miss the deprecation, as nobody jumps over versions
while migrating (e.g, moving directly from 5.4 to 5.6).

Perhaps is it time to clarify our deprecation process into an RFC we
all agree with ?
This RFC could describe a clear deprecation process, from INI settings
deprecation, classes/functions etc... to entire extensions.
As soon as it's clear to everybody and accepted, RMs can do their job
blindly following the RFC.

Julien.P