5.5 to 5.6 cleanup

Hi all,

• ext/mysql

I have little care for those other things. However, there is a massive
amount of mysql_* code (sadly, some of it written recently) out there. Is it
really a good idea to remove it now?

Then again, I suppose it has to be done some day. If it's moved to PECL,
distribution maintainers could include the PECL package.

So I guess I'm not entirely against it, but I'd recommend caution here.

I agree.
IIRC, WordPress 3.8 still uses mysql.

Moving mysql to PECL is mandatory. IMHO.
Intl is better to be moved to PECL also.

There is no point in moving ext/intl to PECL.
the intl stuff which is deprecated in 5.5 is just few functions,
ext/intl stays into PHP.

Julien

18 янв. 2014 г. 3:38 пользователь "Andrea Faulds" ajf@ajf.me написал:

P.S. For gods sakes, did I just saw someone still writing code based on
mysql ext while it is marked as depricated? It is known for years now
that
it is being nuked - frankly I'm surprised it wasn't deleted a long time
ago.

You see it all the time, in good part because of awful PHP tutorials
which promote outdated methods.

--
Andrea Faulds
http://ajf.me/

Tutorials or not, there is so much outdated crap on the internet now, that
any decent human being is able to filter it out.
Old tutorials are not an excuse anymore.

I belive that we are at the point, where anyone who is still sitting on old
libraries like mysql ext, is personaly responsible for his own actions and
can blame only himself. The PHP development has streamlined a lot in last 2
years and part of that process is finally getting rid of old stuff.

On Fri, Jan 17, 2014 at 8:55 PM, Sherif Ramadan theanomaly.is@gmail.comwrote:

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

Actually that was the wrong link to that thread. I mean to refer to this
http://news.php.net/php.internals/63918

On Fri, Jan 17, 2014 at 8:35 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

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