Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] ext/mysql deprecation in 5.5 »

[VOTE] ext/mysql deprecation in 5.5

php.internals

Adam Harvey

13 years ago
All, I've moved the ext/mysql deprecation RFC into the voting phase. You can vote at https://wiki.php.net/rfc/mysql_deprecation — note that, as discussed last week, there are two questions: the first being a simple yes/no question (which will determine whether the RFC is accepted or rejected), and the second to clarify what the preferred course of action will be if the RFC is declined. Please vote on both, unless you particularly wish to abstain from one of the questions. I've also updated the RFC slightly, but not in a way that changes what's actually proposed: Ulf noted that he wasn't comfortable with having the Oracle Wiki link there for converting to MySQLi, so I've replaced that link with another, more recent tutorial (albeit PDO only) and added a link to Ulf's recent blog post about the benefits of mysqli and PDO over ext/mysql. This is mostly useful for documentation purposes, since I think there's general agreement that we should have more resources covering upgrading to newer extensions regardless of the outcome of this RFC. At this stage, I intend to close the vote in a week's time: so Wednesday, December 5. Thanks, Adam, who knows he's a little late with this, but being sick sucks. Sorry.

Adam Harvey

13 years ago
On 28 November 2012 14:03, Adam Harvey <aharvey@php.net> wrote: <big snip, voting open, et cetera> OK, so the first e-mail was the official announcement of voting being open. I'd now like to quickly lay out why I voted yes, and why I think it's the right way forward. Feel free to hit next if your mind is already made up. :) Ulf produced a blackly entertaining timeline of MySQL support in PHP in one of the earlier RFC threads[0]. We've had better options than ext/mysql available in mainline, stable releases since 2004, yet it's taken a long time for there to be a serious push to encourage users to use the newer extensions. There are both a carrot and a stick here. The carrot is well laid out by Ulf in his blog post[1] — the newer extensions are more featureful, faster, and in the case of PDO particularly, easier to use (and harder to misuse). The stick is that we have this faintly ridiculous situation where we have four extensions in php-src for accessing one DBMS, one of which (ext/mysql) is barely maintained and has an API that encourages poor programming practice. Deprecating ext/mysql in PHP 5.5 doesn't mean it's going away immediately. It doesn't even mean it's going away next year: there's no reason at all we can't keep ext/mysql deprecated for more than one release branch. In fact, that would be my preference. As others have said: ext/mysql is a hugely used, popular extension. We can't rip it out overnight, and nor should we. Deprecation is a strong signal. It's a signal that it's time to update tutorials. It's a signal to schedule upgrades for code when new versions are written to use more modern APIs. It's a signal to those of us who speak at conferences, and help people in various fora and various ways that we should redouble our efforts to communicate the benefits of MySQLi and/or PDO. Most of all, it's a signal that we're serious about improving PHP and encouraging our users to improve their own code with us. Thanks for reading. If you got this far, I'll buy you the beer or non-alcoholic substitute of your choice at any conference I'm at next year. (Which, since I'm moving to Vancouver in the new year, may actually be a few.) Adam [0] http://news.php.net/php.internals/63982 [1] http://blog.ulf-wendel.de/2012/php-mysql-why-to-upgrade-extmysql/

Lester Caine

13 years ago
Adam Harvey wrote:
> Deprecation is a strong signal. It's a signal that it's time to update > tutorials. It's a signal to schedule upgrades for code when new > versions are written to use more modern APIs. It's a signal to those > of us who speak at conferences, and help people in various fora and > various ways that we should redouble our efforts to communicate the > benefits of MySQLi and/or PDO.
Since I don't have karma to vote on line I need to raise my objections here. There is no 'objection' to deprecating the extension, but adding E_DEPRECATED to the code is problematic since that should NOT be present in a PECL version of the code? Adding it in one location and not the other does not make sense. ALL that is needed is that the 'extension' is more difficult to access than the preferred alternatives. When MySQL was dropped as 'automatically enabled' and people kept asking 'Where is it?' people accepted the reasoning. Doing the same thing now warning at the loading stage makes this much more practical, since having to disable E_DEPRECATED because of running legacy code and then loosing also the IMPORTANT deprecated warnings is just wrong! I'd almost make a case for moving the currently clean code to PECL now so we CAN load a clean version of mysql if we need to do that. It's bundling it with other deprecated code that is my problem :( Personally I'm only running MySQL to support legacy code, and if this goes ahead then it's another reason to stop upgrading from PHP5.4 ...
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Alexey Zakhlestin

13 years ago
I voted "no", "(b)" We should mention deprecation in manual as hard as possible, we should mention it in ext/mysql/config.m4 and any other place we can reach. Then, at some point (I'm fine with 5.6, but 6.0 would do also), we should just move it to PECL, without using E_DEPRECATED
-- Alexey Zakhlestin, http://github.com/indeyets

Pierre Joye

13 years ago
hi, On Wed, Nov 28, 2012 at 10:55 AM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
> I voted "no", "(b)" > We should mention deprecation in manual as hard as possible, we should > mention it in ext/mysql/config.m4 and any other place we can reach. > Then, at some point (I'm fine with 5.6, but 6.0 would do also), we > should just move it to PECL, without using E_DEPRECATED
That's exactly why we should use E_DEPRECATED now and not in 5.x+1. Also no way to kill it in 5.x, that would be worst than anything else. That being said, let not start this thread, every argument has been mentioned many times already. Let vote. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Philip Olson

13 years ago
On Nov 28, 2012, at 2:08 AM, Pierre Joye wrote:
> hi, > > On Wed, Nov 28, 2012 at 10:55 AM, Alexey Zakhlestin <indeyets@gmail.com> wrote: >> I voted "no", "(b)" >> We should mention deprecation in manual as hard as possible, we should >> mention it in ext/mysql/config.m4 and any other place we can reach. >> Then, at some point (I'm fine with 5.6, but 6.0 would do also), we >> should just move it to PECL, without using E_DEPRECATED > > That's exactly why we should use E_DEPRECATED now and not in 5.x+1. > Also no way to kill it in 5.x, that would be worst than anything else.
The idea of adding E_DEPRECATED now, and then removing it in PECL, is not an opinion held by everyone.
> That being said, let not start this thread, every argument has been > mentioned many times already. Let vote.
The idea of moving it to PECL is not represented in the vote. But it's something to consider as it's a real possibility. It could both symbolize that we are serious about not using ext/mysql, and considering most Linux distros would simply switch to offering the PECL version, it'd probably not break much. Worth thinking about, at least. I'm not yet certain what we should do but this PECL topic is intriguing. Hopefully a few others will weigh in with their related thoughts. Regards, Philip

Nikita Popov

13 years ago
On Wed, Nov 28, 2012 at 11:30 AM, Philip Olson <philip@roshambo.org> wrote:
> The idea of moving it to PECL is not represented in the vote. But > it's something to consider as it's a real possibility. It could > both symbolize that we are serious about not using ext/mysql, and > considering most Linux distros would simply switch to offering the > PECL version, it'd probably not break much. Worth thinking about, > at least. >
Yes, in my eyes it is really pointless to start throwing deprecation warnings and then move it to PECL. Please add the option of a direct PECL-move to the second vote. Nikita

Keisial

13 years ago
I see it as simple to show E_DEPRECATED but not when installed from PECL. 1) Add a int mysql_extension_triggers_deprecated_warning = 1; And use it as a conditional for triggering the warning. 2) Copy the extension code to PECL 3) Add these changes in PECL - If the mysql functions are not already registered, register them with the bundled code. - Set mysql_extension_triggers_deprecated_warning = 0; 4) That's it.

David Muir

13 years ago
On 29/11/12 05:09, Ángel González wrote:
> I see it as simple to show E_DEPRECATED but not when installed from PECL. > > 1) Add a > int mysql_extension_triggers_deprecated_warning = 1; > > And use it as a conditional for triggering the warning. > > 2) Copy the extension code to PECL > > 3) Add these changes in PECL > - If the mysql functions are not already registered, > register them with the bundled code. > - Set mysql_extension_triggers_deprecated_warning = 0; > > 4) That's it. > >
Then people (distros, hosts, etc) will just install it from PECL instead to avoid all the E_DEPRECATED mess. David

Alan Knowles

13 years ago
.. annoying top posting... This is getting close to a good solution. ini option mysql_is_deprecated - can not be set in .ini/htaccess etc, only by ini_set() - so hosters/distros can not fix it... Normally added just before mysql_connect... ini_set('mysql_is_deprecated', "I WILL NOT USE IT IN THE FUTURE"); mysql_connect(......) if the ini value is not set, then mysql_connect() can issue a E_DEPRECATED warning "Mysql is deprecated, use mysqli or PDO, to remove this warning you can set mysql_is_deprecated" They then have to google mysql_is_deprecated, which tells them to use the magic string... Solves: - Users will get warnings on upgrading - it can not be hidden by hosters/distros etc. - Users can easily disable the warning, however they will be explicitly aware of the problem. Backwards/forward compatible.... Regards Alan On Thursday, November 29, 2012 07:00 AM, David Muir wrote:

Martin Nicholls

13 years ago
On 28/11/2012 23:11, Mailing list wrote:
> - Users will get warnings on upgrading - it can not be hidden by > hosters/distros etc.
Think you might be wildly underestimating the ability of both distros and stuff like cPanel to patch the extension. Then again - I think everybody might be.

David Muir

13 years ago
On 29/11/12 10:11, Mailing list wrote:
> .. annoying top posting... > > This is getting close to a good solution. > > ini option mysql_is_deprecated - can not be set in .ini/htaccess etc, > only by ini_set() - so hosters/distros can not fix it... > > Normally added just before mysql_connect... > > ini_set('mysql_is_deprecated', "I WILL NOT USE IT IN THE FUTURE"); > mysql_connect(......) > > if the ini value is not set, then mysql_connect() can issue a > E_DEPRECATED warning > > "Mysql is deprecated, use mysqli or PDO, to remove this warning you > can set mysql_is_deprecated" > > They then have to google mysql_is_deprecated, which tells them to use > the magic string... > > Solves: > - Users will get warnings on upgrading - it can not be hidden by > hosters/distros etc. > - Users can easily disable the warning, however they will be > explicitly aware of the problem. > > Backwards/forward compatible.... > > Regards > Alan > > >
That is indeed a better solution, but again, what happens after moving to PECL? Is this how we want to be deprecating extensions in the future? As mentioned several times in this discussion, this is the first time we're trying to put a whole extension through a language feature/function deprecation process. To me, it's like putting a square through a round hole. Alan's suggestion makes the hole a bit more square. Instead of this being a vote on throwing E_DEPRECATED in ext/mysql, what we really should have is a vote on an RFC on "How to deprecate and remove an extension from core". We can then apply that RFC to any extension we want removed from core. Up until now the process has been to just move it to PECL. Now we're voting to use a different process specifically for ext/mysql because of reasons unknown. I understand the reasons for encouraging people to move to other maintained extensions, but what is the rationale for using a different process specifically for ext/mysql than what we've used in the past? The fact of the matter is, it's not an extension that will be removed. It's an extension that will be *retired from core*. It will continue to be available from PECL. Magic quotes and most of the other examples of "successful" use of deprecation were actually removed from the language. They are no longer available and you can't get them from PECL either. IMHO there shouldn't be a vote on E_DEPRECATED without including future removal plans. Cheers, David

Pierre Joye

13 years ago
hi Alan! On Thu, Nov 29, 2012 at 12:11 AM, Mailing list <alan@akbkhome.com> wrote:
> .. annoying top posting...
Why do you top post too then? :)
> This is getting close to a good solution. > > ini option mysql_is_deprecated - can not be set in .ini/htaccess etc, only > by ini_set() - so hosters/distros can not fix it...
Are you asking to add an option to do exactly the same than the error reporting option does?
> Normally added just before mysql_connect... > > ini_set('mysql_is_deprecated', "I WILL NOT USE IT IN THE FUTURE");
eror_reporting(...);
> mysql_connect(......)
> Solves: > - Users will get warnings on upgrading - it can not be hidden by > hosters/distros etc. > - Users can easily disable the warning, however they will be explicitly > aware of the problem.
Warning on install, on connect and in the doc is not enough? :) And once it is on pecl, we have the superseded/deprecated flag too there. It won't help for distros but distros will follow app leads, as usual. The only reason why distros still provide ext/mysql by default is because the apps require it by default. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Keisial

13 years ago
David Muir wrote:
> On 29/11/12 05:09, Ángel González wrote: >> I see it as simple to show E_DEPRECATED but not when installed from >> PECL. >> >> 1) Add a >> int mysql_extension_triggers_deprecated_warning = 1; >> >> And use it as a conditional for triggering the warning. >> >> 2) Copy the extension code to PECL >> >> 3) Add these changes in PECL >> - If the mysql functions are not already registered, >> register them with the bundled code. >> - Set mysql_extension_triggers_deprecated_warning = 0; >> >> 4) That's it. >> > > Then people (distros, hosts, etc) will just install it from PECL > instead to avoid all the E_DEPRECATED mess. > > David
That's the goal. If they really want the extension they can install it from PECL and they don't get the E_DEPRECATED since that's not coming from core. No triggers-warning, moves-to-PECL, no-longer-triggers. It also provides a supported procedure for installing ext/mysql other than patching php to skip the warning. When someone complains about how they can only use ext/mysql (eg. they are using a code-protected script which uses ext/mysql and is critical for their business...), you can point to PECL, as well as explaining how it doesn't have the same guarantees as php core.

Anthony Ferrara

13 years ago
Angel On Thu, Nov 29, 2012 at 12:02 PM, Ángel González <keisial@gmail.com> wrote:
> David Muir wrote: > > On 29/11/12 05:09, Ángel González wrote: > >> I see it as simple to show E_DEPRECATED but not when installed from > >> PECL. > >> > >> 1) Add a > >> int mysql_extension_triggers_deprecated_warning = 1; > >> > >> And use it as a conditional for triggering the warning. > >> > >> 2) Copy the extension code to PECL > >> > >> 3) Add these changes in PECL > >> - If the mysql functions are not already registered, > >> register them with the bundled code. > >> - Set mysql_extension_triggers_deprecated_warning = 0; > >> > >> 4) That's it. > >> > > > > Then people (distros, hosts, etc) will just install it from PECL > > instead to avoid all the E_DEPRECATED mess. > > > > David > That's the goal. > If they really want the extension they can install it from PECL and they > don't get the E_DEPRECATED since that's not coming from core. > > No triggers-warning, moves-to-PECL, no-longer-triggers. > > It also provides a supported procedure for installing ext/mysql other > than patching php to skip the warning. When someone complains about how > they can only use ext/mysql (eg. they are using a code-protected script > which uses ext/mysql and is critical for their business...), you can > point to PECL, as well as explaining how it doesn't have the same > guarantees as php core.
Just pointing this out: that's NOT what this RFC recommends, and is NOT what's being voted on. This RFC is talking about ONLY adding E_DEPRECATED to core. And the way it's proposed to be done, the "moves-to-PECL" couldn't happen, since it's hard-coded into the core extension... So be careful what you're voting for...

Patrick ALLAERT

13 years ago
2012/11/28 Lester Caine <lester@lsces.co.uk>:
> There is no 'objection' to deprecating the extension, but adding > E_DEPRECATED to the code is problematic since that should NOT be present in > a PECL version of the code?
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not part of the proposed RFC and should certainly not happen. If ext/mysql is deprecated, it can perfectly live in PECL while remaining deprecated. There ARE (supported) replacements for ext/mysql and even if someone really one to use it, it should still be considered deprecated regardless of the repository holding the code.
> Adding it in one location and not the other does > not make sense.
Absolutely! There is no reason to remove that kind of notice in the future.
-- Patrick

Lester Caine

13 years ago
Patrick ALLAERT wrote:
> 2012/11/28 Lester Caine<lester@lsces.co.uk>: >> >There is no 'objection' to deprecating the extension, but adding >> >E_DEPRECATED to the code is problematic since that should NOT be present in >> >a PECL version of the code? > Sorry, but removing the E_DEPRECATED notice when moved to PECL is not > part of the proposed RFC and should certainly not happen. > If ext/mysql is deprecated, it can perfectly live in PECL while > remaining deprecated. There ARE (supported) replacements for ext/mysql > and even if someone really one to use it, it should still be > considered deprecated regardless of the repository holding the code.
>> >Adding it in one location and not the other does >> >not make sense. > Absolutely! There is no reason to remove that kind of notice in the future.
Then perhaps a few more people will start complaining as well then. There is NO reason to have deprecated messages on legacy packages in PECL no other older packages have them? So why pick out this one? This NOT the way to handle retiring well used legacy extensions and it just gets in the way of using E_DEPRECATED when it IS needed! At the very minimum we should be able to ignore warnings when they are well understood without having to hide everything else as well :(
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Reinis Rozitis

13 years ago
> From: Patrick ALLAERT > > Sorry, but removing the E_DEPRECATED notice when moved to PECL is not part > of the proposed RFC and should certainly not happen.
I don't get what is the reason behind it? Yes, the extension is old but it still works perfectly fine and even outperforms the newer mysqli/pdo in some cases and noone will rewrite the legacy apps - so why is there such a hate (I must say) for ISPs and platform providers? If you insist on throwing errors in external pecl extension for me as a server farm administrator it won't leave any choice but to edit the extension code / build custom distro package before putting it on production. rr

Anthony Ferrara

13 years ago
Patrick, Sorry, but removing the E_DEPRECATED notice when moved to PECL is not
> part of the proposed RFC and should certainly not happen. >
The proposal doesn't actually propose anything about a move to PECL. It's listed in the "possible future actions" section exactly once. But the RFC doesn't take a stand on it in either direction. So I'm not sure that you can make that argument.
> Adding it in one location and not the other does > > not make sense. > > Absolutely! There is no reason to remove that kind of notice in the future. >
That's your opinion. Please realize it as such and that other viewpoints also exist. For example, I have the viewpoint that deprecation applies to the LANGUAGE. The inclusion of the extension in the language is what's being deprecated. Even after it's pulled, someone else can maintain it. We can say that you should avoid it, but there's nothing stoping someone else from continuing maintenance of it as a fork. And adding in the other missing functionality (possibly breaking BC, possibly not, whatever). Therefore, in my viewpoint, the deprecation notices only apply to the inclusion of the extension in the core language distribution. Not to the extension itself. I'm not saying that either one of us is right or wrong, just that there are other opinions. To keep this discussion productive, please refrain from using absolutes like that... Thanks Anthony

Kris Craig

13 years ago
On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara <ircmaxell@gmail.com>wrote:
> Patrick, > > > Sorry, but removing the E_DEPRECATED notice when moved to PECL is not > > part of the proposed RFC and should certainly not happen. > > > > The proposal doesn't actually propose anything about a move to PECL. It's > listed in the "possible future actions" section exactly once. But the RFC > doesn't take a stand on it in either direction. So I'm not sure that you > can make that argument. > > > Adding it in one location and not the other does > > > not make sense. > > > > Absolutely! There is no reason to remove that kind of notice in the > future. > > > > That's your opinion. Please realize it as such and that other viewpoints > also exist. > > For example, I have the viewpoint that deprecation applies to the LANGUAGE. > The inclusion of the extension in the language is what's being deprecated. > Even after it's pulled, someone else can maintain it. We can say that you > should avoid it, but there's nothing stoping someone else from continuing > maintenance of it as a fork. And adding in the other missing functionality > (possibly breaking BC, possibly not, whatever). > > Therefore, in my viewpoint, the deprecation notices only apply to the > inclusion of the extension in the core language distribution. Not to the > extension itself. > > I'm not saying that either one of us is right or wrong, just that there are > other opinions. To keep this discussion productive, please refrain from > using absolutes like that... > > Thanks > > Anthony >
I think we're over-complicating this a bit. The whole point of E_DEPRECATED is to get people to stop using an obsolete feature before it's removed (or moved to PECL or whatever; neither of which is in the scope of this RFC anyway). Documentation and whatnot can only accomplish so much. We also know that E_DEPRECATED works when other approaches do not. I would point you all to the famous example of Drupal 7, which would break completely due to a flurry of E_DEPRECATED warnings (if display_errors was set to on) being triggered as of 5.3 due to their continued use of magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released some time later, the code was fixed so that it no longer used those out-dated functions. That's why I voted yes. --Kris

David Muir

13 years ago
On 29/11/12 07:33, Kris Craig wrote:
> On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara <ircmaxell@gmail.com>wrote: > >> Patrick, >> >> >> Sorry, but removing the E_DEPRECATED notice when moved to PECL is not >>> part of the proposed RFC and should certainly not happen. >>> >> The proposal doesn't actually propose anything about a move to PECL. It's >> listed in the "possible future actions" section exactly once. But the RFC >> doesn't take a stand on it in either direction. So I'm not sure that you >> can make that argument. >> >>> Adding it in one location and not the other does >>>> not make sense. >>> Absolutely! There is no reason to remove that kind of notice in the >> future. >> That's your opinion. Please realize it as such and that other viewpoints >> also exist. >> >> For example, I have the viewpoint that deprecation applies to the LANGUAGE. >> The inclusion of the extension in the language is what's being deprecated. >> Even after it's pulled, someone else can maintain it. We can say that you >> should avoid it, but there's nothing stoping someone else from continuing >> maintenance of it as a fork. And adding in the other missing functionality >> (possibly breaking BC, possibly not, whatever). >> >> Therefore, in my viewpoint, the deprecation notices only apply to the >> inclusion of the extension in the core language distribution. Not to the >> extension itself. >> >> I'm not saying that either one of us is right or wrong, just that there are >> other opinions. To keep this discussion productive, please refrain from >> using absolutes like that... >> >> Thanks >> >> Anthony >> > I think we're over-complicating this a bit. The whole point of > E_DEPRECATED is to get people to stop using an obsolete feature before it's > removed (or moved to PECL or whatever; neither of which is in the scope of > this RFC anyway). Documentation and whatnot can only accomplish so much. > > We also know that E_DEPRECATED works when other approaches do not. I would > point you all to the famous example of Drupal 7, which would break > completely due to a flurry of E_DEPRECATED warnings (if display_errors was > set to on) being triggered as of 5.3 due to their continued use of > magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released some > time later, the code was fixed so that it no longer used those out-dated > functions. > > That's why I voted yes. > > --Kris >
Kris, There was no "ext/magic_quotes" that was retired to PECL. You're comparing apples with oranges. David

Kris Craig

13 years ago
> Kris, > > There was no "ext/magic_quotes" that was retired to PECL. You're comparing > apples with oranges. > > David > >
I disagree. Whether we're deprecating an extension or a subset of functions, the practical impact is pretty much the same. As for moving it to PECL, why are we even discussing that here? It's completely outside the scope of this RFC. I imagine moving it to PECL would make the most sense when the time comes, but we shouldn't get ahead of ourselves. We should deprecate it first, then when the time comes (i.e. 6.0) we can figure out where to dump its carcas. Either way, our common goal here is to get people to stop using ext/mysql now so that we can trash it when the time comes. And as far as that goes, I think that what happened with magic_quotes and Drupal is a perfect example of how deprecation can effectively push devs to act when docs and "get the word out" campaigns aren't enough. --Kris

Anthony Ferrara

13 years ago
Kris, I disagree. Whether we're deprecating an extension or a subset of
> functions, the practical impact is pretty much the same. As for moving it > to PECL, why are we even discussing that here? It's completely outside the > scope of this RFC. I imagine moving it to PECL would make the most sense > when the time comes, but we shouldn't get ahead of ourselves. We should > deprecate it first, then when the time comes (i.e. 6.0) we can figure out > where to dump its carcas. >
Actually, it is very much within the scope of this discussion. Case in point, take a look at 5.3.0. The following extensions were moved to PECL: - ext/dbase - ext/fbsql - ext/fdf - ext/ncurses - ext/mhash (BC layer is now entirely within ext/hash) - ext/ming - ext/msql - ext/sybase Now you could make the argument that they weren't as used as ext/mysql. But they were removed from core without raising E_DEPRECATED first. So there definitely is precedent to remove without deprecating first. So it's completely within the realm of discussion here. Either way, our common goal here is to get people to stop using ext/mysql
> now so that we can trash it when the time comes. And as far as that goes, > I think that what happened with magic_quotes and Drupal is a perfect > example of how deprecation can effectively push devs to act when docs and > "get the word out" campaigns aren't enough. >
The problem with this statement is that you're indicating something that didn't happen. "get the word out" campaigns have not happened on an official level for ext/mysql. The wording in the docs is light at best. There has been very little effort from the side of the project to say "get off it now". And that's what some of us have against this concept of raising E_DEPRECATED in 5.5 (or possibly ever)... Anthony

Pierre Joye

13 years ago
hi Anthony, As you are (relatively) new in php.net, let keep the history in mind while comparing things. On Thu, Nov 29, 2012 at 5:28 AM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> Actually, it is very much within the scope of this discussion. > > Case in point, take a look at 5.3.0. The following extensions were moved to > PECL: > > > - ext/dbase > - ext/fbsql > - ext/fdf > - ext/ncurses > - ext/mhash (BC layer is now entirely within ext/hash) > - ext/ming > - ext/msql > - ext/sybase > > Now you could make the argument that they weren't as used as ext/mysql. But > they were removed from core without raising E_DEPRECATED first.
Back to this time, there was no release RFC and it was a simple +/- 1 vote to get an extension out of the distributions. So it is hardly comparable to the current situation.
> So there definitely is precedent to remove without deprecating first. So > it's completely within the realm of discussion here.
No there is not one, not since the RFC introduction. Removing extension in minor (x.y+1 or x.y.z+1) is not allowed.
> The problem with this statement is that you're indicating something that > didn't happen. "get the word out" campaigns have not happened on an > official level for ext/mysql. The wording in the docs is light at best. > There has been very little effort from the side of the project to say "get > off it now". And that's what some of us have against this concept of > raising E_DEPRECATED in 5.5 (or possibly ever)...
With the risk to repeat myself here (like 99.99% of the posts in this thread), almost all major projects out there have zero issue with the deprecation flag. They even agree to get it as it will help to convince their developers and users to update their code and setups. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Johannes Schlueter

13 years ago
On Wed, 2012-11-28 at 23:28 -0500, Anthony Ferrara wrote:
> Case in point, take a look at 5.3.0. The following extensions were moved to > PECL: > > > - ext/dbase > - ext/fbsql > - ext/fdf > - ext/ncurses > - ext/mhash (BC layer is now entirely within ext/hash) > - ext/ming > - ext/msql > - ext/sybase > > > Now you could make the argument that they weren't as used as ext/mysql. But > they were removed from core without raising E_DEPRECATED first.
There is another argument: Those aren't deprecated. They were just moved. Aside from mhash it is still fine to use those, we simply don't bundle them anymore. For mhash there is an equivalent replacement in the distribution. With ext/mysql it is about "don't use this anymore. Use mysqli or such" johannes

Lester Caine

13 years ago
Kris Craig wrote:
> Either way, our common goal here is to get people to stop using ext/mysql now so > that we can trash it when the time comes. And as far as that goes, I think that > what happened with magic_quotes and Drupal is a perfect example of how > deprecation can effectively push devs to act when docs and "get the word out" > campaigns aren't enough.
The use of 'Drupal' as an example is totally spurious here. E_DEPRECATED and E_STRICT upgrades to any framework needed to be managed and in many cases switching to later versions of PHP are ALWAYS linked to a new major version of the framework. It is because the older versions are still expected to work with older versions of PHP. I'm sure you will find today that most of these frameworks ACTUALLY disable E_STRICT and E_DEPRECATED by default so that they continue to run on on the range of PHP versions they were originally designed for? Making something that only works with PHP5.4 is simply not practical when the bulk of the hosting is still on PHP5.2! Drupal is not the only framework that has to support it live user base. This does return to something that people have got irritated with me before but has been highlighted again here. Extensions are NOT core to PHP and most distributions including the windows ones do not provide a single executable for PHP but rather allow one to select what is loaded manually. I think it is quite obvious that even if E_DEPRECATED gets added to an 'official' distribution of mysql in PHP, that this will get stripped back out by the distributions as inappropriate in modular distributions? So why create the agro in the first place? It IS the education that is missing ... but equally there ARE still valid reasons to use mysql just as there are for the list of other retired extensions listed here. Creating even more problems for users is simply counter productive when there is STILL a need to educate users as to how to make their PHP5.2 code 'work' with PHP5.3/4 so that ISP's ARE in a position TO upgrade at all! And I speak with my 'hosting' hat on here.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Jan Ehrhardt

13 years ago
Kris Craig in php.internals (Wed, 28 Nov 2012 12:33:55 -0800):
>We also know that E_DEPRECATED works when other approaches do not. I would >point you all to the famous example of Drupal 7, which would break >completely due to a flurry of E_DEPRECATED warnings (if display_errors was >set to on) being triggered as of 5.3 due to their continued use of >magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released some >time later, the code was fixed so that it no longer used those out-dated >functions.
http://drupal.org/community-initiatives/drupal-core Drupal 8 will not be released before August 2013. Maybe in the current core the E_DEPRECATED warnings are gone, but certainly not in many of the modules. People are still switching to Drupal7. And Drupal7 throws the watchdog full with E_DEPRECATED warnings when it is running onder PHP5.4. The views module has issues with PHP 5.4, but some modules even let Drupal7 under PHP5.4 crash completely: http://drupal.org/node/1831402 If E_DEPRECATED stays in ext/mysql even after it has moved to PECL, the result will be that more and more people turn E_DEPRECATED warnings off. Jan

Remi Collet

13 years ago
My 0,02€ Could it be possible to add in "deprecated" field in the zend_module_entry structure, add 0 value in STANDARD_MODULE_PROPERTIES_EX add 1 value in DEPRECATED_MODULE_PROPERTIES_EX (new constant) And then, only throw a message during initial module load. This will produce really less noice. Regards, Remi.

Kris Craig

13 years ago
On Thu, Nov 29, 2012 at 7:46 AM, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote:
> Kris Craig in php.internals (Wed, 28 Nov 2012 12:33:55 -0800): > >We also know that E_DEPRECATED works when other approaches do not. I > would > >point you all to the famous example of Drupal 7, which would break > >completely due to a flurry of E_DEPRECATED warnings (if display_errors was > >set to on) being triggered as of 5.3 due to their continued use of > >magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released > some > >time later, the code was fixed so that it no longer used those out-dated > >functions. > > http://drupal.org/community-initiatives/drupal-core > Drupal 8 will not be released before August 2013. Maybe in the current > core the E_DEPRECATED warnings are gone, but certainly not in many of > the modules. > > People are still switching to Drupal7. And Drupal7 throws the watchdog > full with E_DEPRECATED warnings when it is running onder PHP5.4. The > views module has issues with PHP 5.4, but some modules even let Drupal7 > under PHP5.4 crash completely: > http://drupal.org/node/1831402 > > If E_DEPRECATED stays in ext/mysql even after it has moved to PECL, the > result will be that more and more people turn E_DEPRECATED warnings off. >
I think you're forgetting though that the same applies to PHP itself. Many repos still default to PHP 5.1.x. Adoption always tends to be a lagging factor. I don't see any evidence to suggest that Drupal and other distros have even slower adoption rates than PHP. In fact, the opposite seems to be true from what I've observed. In other words, most of these people you referenced who are still using Drupal 6 are probably still using an older version of PHP as well. Therefore, most people using Drupal 7 probably don't have to worry about the deprecation because they haven't upgraded to 5.3.3+ yet. But it did affect enough people that it forced the Drupal devs to update their code to conform to the changes in PHP. We shouldn't be targetting future PHP releases to sync with older distros simply because many people still use them. Given that most people tend to use older versions of PHP as well, I believe it's safe to say that the two cancel one another out. --Kris

Anthony Ferrara

13 years ago
Kris I think you're forgetting though that the same applies to PHP itself. Many
> repos still default to PHP 5.1.x. Adoption always tends to be a lagging > factor. I don't see any evidence to suggest that Drupal and other distros > have even slower adoption rates than PHP. In fact, the opposite seems to > be true from what I've observed. > > In other words, most of these people you referenced who are still using > Drupal 6 are probably still using an older version of PHP as well. > Therefore, most people using Drupal 7 probably don't have to worry about > the deprecation because they haven't upgraded to 5.3.3+ yet. But it did > affect enough people that it forced the Drupal devs to update their code to > conform to the changes in PHP. > > We shouldn't be targetting future PHP releases to sync with older distros > simply because many people still use them. Given that most people tend to > use older versions of PHP as well, I believe it's safe to say that the two > cancel one another out. >
In my opinion, this attitude is the exact wrong one for core to take. We should be trying to make adoption easier and removing barriers to projects and hosts upgrading, not relying on the fact that they don't to justify our actions. If we make the lives easier for developers and hosts, then we won't have the problems of lagging adoption. If we rely on the lagging adoption to justify changes, then the circle feeds itself. We shouldn't be relying on slow adoption for ANY decision. By doing that, we're ensuring slow adoption. And slow adoption hurts EVERYONE. It hurts us from the standpoint that we need to maintain software longer (or at least there's pressure to). It hurts us from the standpoint that feedback on new versions is reduced significantly. It hurts developers in that they can't take advantage of new features. It hurts developer because software doesn't get fixed for a long time. It hurts projects because they can't take advantage of new features for a long time. It hurts hosts in that they can't take advantage of performance improvements (that are sometimes very significant). The only group that benefits from long adoption cycles is the linux distribution folks. Because the longer it takes for our stuff to get adopted, the more it seems like their decision to have a long term version sane. But if adoption of new versions is as seamless as possible, and easy on everyone, then it makes that decision seem archaic and arbitrary. Low barriers means everyone wins. High barriers just exacerbates everyone's pain. Let's push for low barriers... Anthony

Kris Craig

13 years ago
On Thu, Nov 29, 2012 at 10:03 AM, Anthony Ferrara <ircmaxell@gmail.com>wrote:
> Kris > > > I think you're forgetting though that the same applies to PHP itself. Many >> repos still default to PHP 5.1.x. Adoption always tends to be a lagging >> factor. I don't see any evidence to suggest that Drupal and other distros >> have even slower adoption rates than PHP. In fact, the opposite seems to >> be true from what I've observed. >> >> In other words, most of these people you referenced who are still using >> Drupal 6 are probably still using an older version of PHP as well. >> Therefore, most people using Drupal 7 probably don't have to worry about >> the deprecation because they haven't upgraded to 5.3.3+ yet. But it did >> affect enough people that it forced the Drupal devs to update their code >> to >> conform to the changes in PHP. >> >> We shouldn't be targetting future PHP releases to sync with older distros >> simply because many people still use them. Given that most people tend to >> use older versions of PHP as well, I believe it's safe to say that the two >> cancel one another out. >> > > In my opinion, this attitude is the exact wrong one for core to take. We > should be trying to make adoption easier and removing barriers to projects > and hosts upgrading, not relying on the fact that they don't to justify our > actions. > > If we make the lives easier for developers and hosts, then we won't have > the problems of lagging adoption. If we rely on the lagging adoption to > justify changes, then the circle feeds itself. > > We shouldn't be relying on slow adoption for ANY decision. By doing that, > we're ensuring slow adoption. And slow adoption hurts EVERYONE. It hurts us > from the standpoint that we need to maintain software longer (or at least > there's pressure to). It hurts us from the standpoint that feedback on new > versions is reduced significantly. It hurts developers in that they can't > take advantage of new features. It hurts developer because software doesn't > get fixed for a long time. It hurts projects because they can't take > advantage of new features for a long time. It hurts hosts in that they > can't take advantage of performance improvements (that are sometimes very > significant). > > The only group that benefits from long adoption cycles is the linux > distribution folks. Because the longer it takes for our stuff to get > adopted, the more it seems like their decision to have a long term version > sane. But if adoption of new versions is as seamless as possible, and easy > on everyone, then it makes that decision seem archaic and arbitrary. > > Low barriers means everyone wins. High barriers > just exacerbates everyone's pain. > > Let's push for low barriers... > > Anthony >
I do agree with you in principle, Anthony. What I'm saying is that the reality !== the ideal. Slow adoption is just a fact of life. Every IT person I've ever worked with was trained to be cautious and to "go with what we know is stable and works, not with what's new." If distros like Drupal were to get fast adoption and we were to get fast adoption, then that would be super awesome. So long as out adoption rate isn't faster than theirs (which I don't think it would be even if we tried), then these barriers will not exist for most people because the distros will update themselves to conform to PHP long before they ever upgrade anyway. --Kris

Pierre Joye

13 years ago
hi Jan, On Thu, Nov 29, 2012 at 4:46 PM, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote:
> Kris Craig in php.internals (Wed, 28 Nov 2012 12:33:55 -0800): >>We also know that E_DEPRECATED works when other approaches do not. I would >>point you all to the famous example of Drupal 7, which would break >>completely due to a flurry of E_DEPRECATED warnings (if display_errors was >>set to on) being triggered as of 5.3 due to their continued use of >>magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released some >>time later, the code was fixed so that it no longer used those out-dated >>functions. > > http://drupal.org/community-initiatives/drupal-core > Drupal 8 will not be released before August 2013. Maybe in the current > core the E_DEPRECATED warnings are gone, but certainly not in many of > the modules.
Drupal 7 supports PDO. There is no such thing like mysqli or mysql as driver.
> People are still switching to Drupal7. And Drupal7 throws the watchdog > full with E_DEPRECATED warnings when it is running onder PHP5.4. The > views module has issues with PHP 5.4, but some modules even let Drupal7 > under PHP5.4 crash completely: > http://drupal.org/node/1831402
If there is a crash, a bug at bugs.php.net should be reported.
> If E_DEPRECATED stays in ext/mysql even after it has moved to PECL, the > result will be that more and more people turn E_DEPRECATED warnings off.
And? Where is the problem? The idea is to have it on in dev not in prod. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Anthony Ferrara

13 years ago
Adam, Thanks for opening voting. However, I'd like to ask you to do something else here. Can you please update the RFC to reflect the discussions that happened on list? Not everything that was talked about, but the major discussion points at least. That way it's there for future reference, and people who didn't read the entire discussion thread can get a summary before they vote. As it sits now, it doesn't really present all sides of the issue well... Thanks Anthony On Wed, Nov 28, 2012 at 1:03 AM, Adam Harvey <aharvey@php.net> wrote:

Adam Harvey

13 years ago
On 29 November 2012 00:36, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> However, I'd like to ask you to do something else here. Can you please > update the RFC to reflect the discussions that happened on list? Not > everything that was talked about, but the major discussion points at least. > That way it's there for future reference, and people who didn't read the > entire discussion thread can get a summary before they vote. As it sits now, > it doesn't really present all sides of the issue well...
I agree — I actually was hoping to update the RFC post-discussion to reflect what had been discussed, but I've had a bit of a perfect storm of problems this week that have prevented me from putting any real time into PHP matters. I can have a look at revising the RFC on the weekend, but if you or someone else wanted to summarise the main "no" position and insert it before that, I'd have absolutely no objections. Thanks, Adam

Kalle Sommer Nielsen

13 years ago
2012/11/28 Adam Harvey <aharvey@php.net>:
> At this stage, I intend to close the vote in a week's time: so > Wednesday, December 5.
+1 for deprecation in 5.5
-- regards, Kalle Sommer Nielsen kalle@php.net