[PHP-DEV] RFC: ext/mysql deprecation
Hi everyone, I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will hasten the move of users to the more modern (and supported) APIs available: mysqli and PDO, and that this process will also likely encourage some users to switch to safer patterns such as prepared queries at the same time. I must apologise for the lateness of this RFC: I had hoped to do this some time before alpha 1, but travel and illness have taken their toll. Better late than never! So, please provide comments, feedback, concerns, and so on. Obviously, this isn't going to a vote for at least a couple of weeks, but earlier feedback is better. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 2012-11-12 17:00, Adam Harvey wrote: Hi everyone, I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. While I fully understand the reasons behind this, I still believe this kind of thing should be done using the documentation only. Generating 'educational' notices will just annoy the end users and in 99% cases they can't do a thing about it - nobody's going to rewrite a large piece of legacy software just to make PHP happy. More notices doesn't necessarily mean less people are going to use ext/mysql, you can't hasten users to move if they don't really want to do it themselves. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Mon, 2012-11-12 at 21:00 +0800, Adam Harvey wrote: logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will Short comment: Those will mostly be unseen. Most people use the @ operator to silence errors on these functions, so such deprecation notices would go unseen. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Mon, Nov 12, 2012 at 2:20 PM, Antony Dovgal t...@daylessday.org wrote: On 2012-11-12 17:00, Adam Harvey wrote: Hi everyone, I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. While I fully understand the reasons behind this, I still believe this kind of thing should be done using the documentation only. Generating 'educational' notices will just annoy the end users and in 99% cases they can't do a thing about it - nobody's going to rewrite a large piece of legacy software just to make PHP happy. More notices doesn't necessarily mean less people are going to use ext/mysql, you can't hasten users to move if they don't really want to do it themselves. Well, I think we can communicate, then educate people so that they dont use ext/mysql any more. It will take the time needed, but if we want this move to come up, we need to start it. Doing nothing about it, things wont move. I like educating through the documentation / through conferences, then through the code, using the designed-for-that E_DEPRECATED , then removing the extension. It may take years, but such a project should be clear to everybody (RFC), accepted, and started :) Julien.Pauli -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 12 November 2012 21:20, Antony Dovgal t...@daylessday.org wrote: While I fully understand the reasons behind this, I still believe this kind of thing should be done using the documentation only. Generating 'educational' notices will just annoy the end users and in 99% cases they can't do a thing about it - nobody's going to rewrite a large piece of legacy software just to make PHP happy. More notices doesn't necessarily mean less people are going to use ext/mysql, you can't hasten users to move if they don't really want to do it themselves. I don't think the documentation is necessarily effective here, particularly with functions that users tend to know by heart: to pick on session_register() and friends as an example, it seemed like the E_DEPRECATED notice added in 5.3.0 was the impetus for quite a few people to come out of the woodwork on IRC and start asking about $_SESSION, even though it had been listed as deprecated in the manual for at least 12 months before that. I'm not really convinced the average user ever looks at the manual for things they know, truth be told. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 12 November 2012 21:48, Johannes Schlüter johannes.schlue...@oracle.com wrote: On Mon, 2012-11-12 at 21:00 +0800, Adam Harvey wrote: logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will Short comment: Those will mostly be unseen. Most people use the @ operator to silence errors on these functions, so such deprecation notices would go unseen. There are some users we're never going to reach, short of removing the functions altogether. It's the same for everything we deprecate or remove — the screaming about ext/sqlite being removed in 5.4 is still there, for instance, and will probably only increase as distros roll out 5.4 packages. A five second Google Code Search suggests the ratio of suppressed calls to mysql_connect() to unsuppressed ones is about 2:11*, at least within its increasingly out of date corpus. Admittedly, many of the users of the unsuppressed code aren't going to have error reporting turned on anyway, but I don't think the situation's dire. All that said, is there a different function we could hook into that does make more sense? Adam * No statistical validity claimed. I'm not Nate Silver, nor do I play him on TV. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 12 November 2012 22:01, jpauli jpa...@php.net wrote: Well, I think we can communicate, then educate people so that they dont use ext/mysql any more. It will take the time needed, but if we want this move to come up, we need to start it. Doing nothing about it, things wont move. I like educating through the documentation / through conferences, then through the code, using the designed-for-that E_DEPRECATED , then removing the extension. It may take years, but such a project should be clear to everybody (RFC), accepted, and started :) I agree, but I feel as though we started this process last year. (Informally, really, we'd been doing it for a while before that.) It may or may not be too early to attach E_DEPRECATED to mysql_connect() — that's why I'm asking. Obviously, I think it's a reasonable time, personally, but fortunately for everyone, I'm not the arbiter of what goes into PHP. Adam, who promises not to reply to any other e-mails until tomorrow. Mostly because it's nearing on bedtime. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/12/2012 02:20 PM, Antony Dovgal wrote: While I fully understand the reasons behind this, I still believe this kind of thing should be done using the documentation only. following that argument we can deprecate E_DEPRECATED altogether, can't we? -1 -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Mon, 12 Nov 2012, Johannes Schlüter wrote: On Mon, 2012-11-12 at 21:00 +0800, Adam Harvey wrote: logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will Short comment: Those will mostly be unseen. Most people use the @ operator to silence errors on these functions, so such deprecation notices would go unseen. Also, that type of users won't upgrade PHP anyway... cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 11.2012 14:00, schrieb Adam Harvey: I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. Adam, I am more than happy someone who is not paid by MySQL took the time to write an RFC. I/we have been trying to sing the stop using ext/mysql-song since at least since 2006. We put ext/mysql in a (security) bug fix maintenance mode only years ago. Too many ignore those attempts to get rid of ext/mysql. I searched a major search engine for PHP MySQL tutorials a few months ago. 9 out of the top 10 search results demonstrated how to use ext/mysql. 90% are of the tutorials are ashaming junk in my eyes. Wake them up. The year 2013 is just around the corner... However, because of the documentation situation, we waited and waited. You initiative seems to show that the deprecation message has finally reached circles outside MySQL. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 2012-11-12 18:15, Adam Harvey wrote: I don't think the documentation is necessarily effective here, particularly with functions that users tend to know by heart skip I'm not really convinced the average user ever looks at the manual for things they know, truth be told. Well, I'd expect people actively developing applications in PHP to use the docs from time to time. But my concern is for people using legacy apps. True, they might not use the docs at all and the only warning they'll get when they do their usual PHP upgrade is error logs stuffed full of E_DEPRECATED. So what is they going to do in that case? Disable the notice, of course. Just a random thought: is it possible to 'emulate' ext/mysql funcs using, say, ext/mysqli, similar to how ext/mhash functions are now emulated by ext/hash? -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
My standpoint would be not to add E_DEPRECATED notices in 5.5... It's simply used too much to start loudly complaining about it. Instead, what I would suggest is the following: 1. Officially deprecate it now. Right now, on the docs it says discouraged, but I would suggest changing that to officially deprecated. 2. The next release (5.6 or 6) would add deprecation errors to the code. 3. The next release (5.7 or 6 or 6.1, etc) would then remove the extension entirely. That way there's a significant roadmap towards deprecation, and people can migrate their code in tune. Sure, there are people who won't do anything and will break on that major release, but there's not much we can do about that anyway... Just my $0.02...
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 12.11.2012 15:48, schrieb Antony Dovgal: On 2012-11-12 18:15, Adam Harvey wrote: I don't think the documentation is necessarily effective here, particularly with functions that users tend to know by heart skip I'm not really convinced the average user ever looks at the manual for things they know, truth be told. Well, I'd expect people actively developing applications in PHP to use the docs from time to time. But my concern is for people using legacy apps. True, they might not use the docs at all and the only warning they'll get when they do their usual PHP upgrade is error logs stuffed full of E_DEPRECATED. So what is they going to do in that case? Disable the notice, of course. Don't bother. There is a standard way of deprecation, at least I assume there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
hi! On Mon, Nov 12, 2012 at 2:00 PM, Adam Harvey ahar...@php.net wrote: I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will hasten the move of users to the more modern (and supported) APIs available: mysqli and PDO, and that this process will also likely encourage some users to switch to safer patterns such as prepared queries at the same time. I must apologise for the lateness of this RFC: I had hoped to do this some time before alpha 1, but travel and illness have taken their toll. Better late than never! So, please provide comments, feedback, concerns, and so on. Obviously, this isn't going to a vote for at least a couple of weeks, but earlier feedback is better. Huge +1. The same arguments against deprecating it have been used for years without effects. Time to use a different approach. Also the mysql team provides a script which wraps the newers APIs into a ext/mysql api, allowing easy migration by including it. adding Ulf to the loop too. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hi, We put ext/mysql in a (security) bug fix maintenance mode only years ago. Too many ignore those attempts to get rid of ext/mysql. Maybe it's time to put it into full non-maintenance mode then? I believe MySQL is one of the on-by-default extensions when you compile PHP blindly (as I'm sure many do), why not make it require enabling specifically during build configuration, along with an end-of-script message that states the extension is no longer maintained (not even security fixes). 2. The next release (5.6 or 6) would add deprecation errors to the code. I think a major version jump would be a good enough excuse to just drop it entirely ;) I'd like to see your list moved up one peg though. If you're going to official deprecate in the docs, why would you wait until the next version to add deprecation notices to the code? In my opinion the more visible we make it now (and sooner we get all of the whining out of the way) the better it will be for all parties. So I'd like to see deprecation errors in 5.5, and removal in 5.6 which is still at least around 18 months away (if we estimate based on the time between 5.4 and 5.5). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 12.11.2012 15:41, schrieb Ulf Wendel: Am 11.2012 14:00, schrieb Adam Harvey: I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. Adam, I am more than happy someone who is not paid by MySQL took the time to write an RFC. I/we have been trying to sing the stop using ext/mysql-song since at least since 2006. We put ext/mysql in a (security) bug fix maintenance mode only years ago. Too many ignore those attempts to get rid of ext/mysql. I searched a major search engine for PHP MySQL tutorials a few months ago. 9 out of the top 10 search results demonstrated how to use ext/mysql. 90% are of the tutorials are ashaming junk in my eyes. Wake them up. The year 2013 is just around the corner... However, because of the documentation situation, we waited and waited. You initiative seems to show that the deprecation message has finally reached circles outside MySQL. Ulf I think the best way of getting rid of trash php tutorials is not catering to their wrong ways. Run the standard deprecate-remove cycle instead, as you and most of us prefer. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hello all! Julien this weekend was at the conference in Riga and we talked with him exactly about this, how it could be handled and stuff. The bottom line of our discussion was that I expressed the opinion that things should really start to move as of 5.5 - postponing it will not make any difference, because people will start to move only when it starts to generate some warnings and errors. Until then you can educate them as much as you want - they just ignore it. Everyone who was susceptible to education is already educated :) Just my 2 cents. P.S. Kill the PDO too, this topic was also was discussed heavily.
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Mon, Nov 12, 2012 at 8:57 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: Hello all! Julien this weekend was at the conference in Riga and we talked with him exactly about this, how it could be handled and stuff. The bottom line of our discussion was that I expressed the opinion that things should really start to move as of 5.5 - postponing it will not make any difference, because people will start to move only when it starts to generate some warnings and errors. Until then you can educate them as much as you want - they just ignore it. Everyone who was susceptible to education is already educated :) Agreed. P.S. Kill the PDO too, this topic was also was discussed heavily. Strongly disagreed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Mon, Nov 12, 2012 at 4:57 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: Hello all! Julien this weekend was at the conference in Riga and we talked with him exactly about this, how it could be handled and stuff. The bottom line of our discussion was that I expressed the opinion that things should really start to move as of 5.5 - postponing it will not make any difference, because people will start to move only when it starts to generate some warnings and errors. Until then you can educate them as much as you want - they just ignore it. Everyone who was susceptible to education is already educated :) Yes, it's crazy we talked about that exactly yesterday, and today someone posts an RFC about that. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Mon, 12 Nov 2012, Adam Harvey wrote: I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will hasten the move of users to the more modern (and supported) APIs available: mysqli and PDO, and that this process will also likely encourage some users to switch to safer patterns such as prepared queries at the same time. IMO, there doesn't need to be a discussion on *how* to deprecate ext/mysql. We have E_DEPRECATED for that, just like you write in your RFC. The only question is do we want to deprecate it?. On that one: +1 cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Mon, Nov 12, 2012 at 4:00 PM, Ulf Wendel ulf.wen...@oracle.com wrote: Am 12.11.2012 15:48, schrieb Antony Dovgal: On 2012-11-12 18:15, Adam Harvey wrote: I don't think the documentation is necessarily effective here, particularly with functions that users tend to know by heart skip I'm not really convinced the average user ever looks at the manual for things they know, truth be told. Well, I'd expect people actively developing applications in PHP to use the docs from time to time. But my concern is for people using legacy apps. True, they might not use the docs at all and the only warning they'll get when they do their usual PHP upgrade is error logs stuffed full of E_DEPRECATED. So what is they going to do in that case? Disable the notice, of course. Don't bother. There is a standard way of deprecation, at least I assume there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove. Ulf Hi, I agree to deprecate/remove on the long run, but I think that we should wait for the next version for doing so. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hi 2012/11/12 Ferenc Kovacs tyr...@gmail.com I agree to deprecate/remove on the long run, but I think that we should wait for the next version for doing so. Wait for the next version? Sorry but thats years away, and where does that put us? No where in all honestly, if we don't do something actively against this problem, which indeed is a problem for us and especially the MySQL guys that a literally forced to support it. TL;DR, if we don't do it now, we just keep postponing it and nothing will happen. +1 on the RFC -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/12/2012 07:24 AM, Leigh wrote: Hi, We put ext/mysql in a (security) bug fix maintenance mode only years ago. Too many ignore those attempts to get rid of ext/mysql. Maybe it's time to put it into full non-maintenance mode then? I believe MySQL is one of the on-by-default extensions when you compile PHP blindly (as I'm sure many do), why not make it require enabling specifically during build configuration, along with an end-of-script message that states the extension is no longer maintained (not even security fixes). That is simply not true. If you download PHP and do ./configure make install you do not get MySQL support. You have to explicitly specify that you want it. What is true is that most people no longer build PHP at all. They just end up with whatever their provider has installed or with whatever packages they end up installing when they install the PHP app they want to use. Both Wordpress and Drupal depends on php-mysql on Ubuntu, for example. It would be good if we could get the majority of the major PHP apps to commit to supporting mysqli along the same timeframe as marking this deprecated. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/12/2012 05:00 AM, Adam Harvey wrote: Hi everyone, I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will hasten the move of users to the more modern (and supported) APIs available: mysqli and PDO, and that this process will also likely encourage some users to switch to safer patterns such as prepared queries at the same time. I must apologise for the lateness of this RFC: I had hoped to do this some time before alpha 1, but travel and illness have taken their toll. Better late than never! So, please provide comments, feedback, concerns, and so on. Obviously, this isn't going to a vote for at least a couple of weeks, but earlier feedback is better. Thanks, Adam I'm +1 on using E_DEPRECATED. Anything beyond that would be -1 since it is likely to break BC (I note that the Release Process RFC doesn't defines compatibility, but I think we are have a gut feel for what it means) Adam, can you: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi 2. Mention how to turn off E_DEPRECATED warnings in the RFC? When users of 5.5 stumble on the new messages, we can then simply point them to the RFC. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Mon, Nov 12, 2012 at 9:50 AM, Anthony Ferrara ircmax...@gmail.com wrote: My standpoint would be not to add E_DEPRECATED notices in 5.5... It's simply used too much to start loudly complaining about it. Instead, what I would suggest is the following: 1. Officially deprecate it now. Right now, on the docs it says discouraged, but I would suggest changing that to officially deprecated. 2. The next release (5.6 or 6) would add deprecation errors to the code. 3. The next release (5.7 or 6 or 6.1, etc) would then remove the extension entirely. I have to disagree with these suggestions. Whether you say it's official or not in the documentation rarely seems to discourage people from using it. As Adam pointed out, the deprecation error moved people, with aforementioned functions, to take action, and most people do not pay much attention to the documentation when it comes to functions they've been using for years. At least that seems to be the majority response. I believe the E_DEPRECATED warning is over due here. This has been talked about for years. The one constant I notice among the PHP community is that they are incredibly resistant to take action. I can understand that some of this resistance is justified and not without good reason, but most of it is just procrastination. Lets not sit on this one until the next release, because -- if I recall correctly -- that's the same thing that was said during the last release. It's been over a year since the Alpha release of PHP 5.4 and nearly 2 years since 5.2 has been EOL. There's plenty of wiggle room in there for the majority of PHP users to become content with ext/mysql being deprecated. Because there are still people on 5.2 despite it being EOL, and plenty that have only recently made the move to 5.3, which is soon to be EOL. The time it will take those to move to 5.4 is likely the time it will take for whatever comes after 5.5 to be stable. Those that are running legacy code dependent on ext/mysql can choose to not upgrade as always. That way there's a significant roadmap towards deprecation, and people can migrate their code in tune. Sure, there are people who won't do anything and will break on that major release, but there's not much we can do about that anyway... Just my $0.02... Giving people more time and more opportunity to continue using an extension that is no longer maintained is hardly worthwhile. There's already a good migration document available and plenty of people are only finding it by chance when the realize ext/mysql was soft-deprecated. More are likely to find it and begin a swift path to migration once they start seeing E_DEPRECATED errors. As for projects that still depend on ext/mysql, like some of the popular CMS software out there, this will only compound the effect in that their communities and user bases will urge those projects to step up support to the new extensions in the future. Remember, It'll likely be years before most of those user bases start finding PHP 5.5 as a default with their hosts. This is plenty of time in my opinion. Postponing this for a few more years makes no sense. I'm all for throwing E_DEPRECATED in ext/mysql in 5.5 :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 13 November 2012 08:44, Christopher Jones christopher.jo...@oracle.com wrote: Adam, can you: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi 2. Mention how to turn off E_DEPRECATED warnings in the RFC? When users of 5.5 stumble on the new messages, we can then simply point them to the RFC. Done and done. I've added a (short) workarounds section towards the bottom, which can be moved up later if the RFC is accepted. Against that, I'm not a big fan of RFCs as documentation, but that's a separate discussion. :) Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 13 November 2012 01:16, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Nov 12, 2012 at 4:00 PM, Ulf Wendel ulf.wen...@oracle.com wrote: Don't bother. There is a standard way of deprecation, at least I assume there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove. I agree to deprecate/remove on the long run, but I think that we should wait for the next version for doing so. Honestly, if we were going to delay the eventual removal (and I'm not sure we should), I'd rather have an extra release cycle with E_DEPRECATED, rather than an extra release cycle with documentation-only warnings that are more easily ignored — so either way, I'd still want the notices in 5.5. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/12/2012 07:08 PM, Adam Harvey wrote: On 13 November 2012 08:44, Christopher Jones christopher.jo...@oracle.com wrote: Adam, can you: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi 2. Mention how to turn off E_DEPRECATED warnings in the RFC? When users of 5.5 stumble on the new messages, we can then simply point them to the RFC. Done and done. I've added a (short) workarounds section towards the bottom, which can be moved up later if the RFC is accepted. Against that, I'm not a big fan of RFCs as documentation, but that's a separate discussion. :) Content like this deserves to be in RFCs so voters can quickly judge the impact of proposed changes on end users. Thanks for adding it, Chris Adam -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 2012-11-13, Adam Harvey ahar...@php.net wrote: On 13 November 2012 01:16, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Nov 12, 2012 at 4:00 PM, Ulf Wendel ulf.wen...@oracle.com wrote: Don't bother. There is a standard way of deprecation, at least I assume there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove. I agree to deprecate/remove on the long run, but I think that we should wait for the next version for doing so. Honestly, if we were going to delay the eventual removal (and I'm not sure we should), I'd rather have an extra release cycle with E_DEPRECATED, rather than an extra release cycle with documentation-only warnings that are more easily ignored ? so either way, I'd still want the notices in 5.5. Personally I think we should E_DEPRECATE it. We will have enough time till 5.5 RC1 to decide on the RFC within the regular 2-4 weeks. +1 from me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
