On Thu, Nov 15, 2012 at 7:40 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > Sherif, > >> I'm just trying to understand your reasoning behind this view. >> >> How is "telling people it's deprecated, but only in the manual" going >> to be any different than "putting warnings to discourage future use, >> but only in the manual"? > > > I'm not saying to put it only in the manual. I'm saying we need to make it > clear in the manual. And then we need to go on an education campaign by > speaking in conferences, blogging, writing tutorials, reaching out to the > sites that host bad ones and trying to get them to switch. Basically make an > actual effort to convey the gravity of the situation, rather than just > writing a quick quarter of a paragraph note "We recommend you don't use > these"... > >> >> 1) People who use mysql_* will rarely ever look at the manual to see them. > > > I don't have stats, but in the people I've talked to who use that > functionality (in chat rooms, etc), they often link directly to the docs. > That may be overestimating the population, but I think more people read the > docs than you think. Now, they may start to use it before they look at the > docs (from tutorials), but they will likely visit the docs at some point... > >> >> 2) Even if they do they do what makes you think this is more effective >> than seeing the warning in their logs? > > > It's not that it's more effective. That's not what I'm after. If I was after > "effective", I'd say let's remove it in 5.5. That's effective. But it's also > not *good*. I want to give reasonable people a reasonable chance. And by > controlling the message, I think we can do that. > >> >> 3) Even if it was more effective, what makes you think it will result >> in any kind of action beyond that of which the warnings would result? > > > There are going to be some people who will never change. And there's nothing > we can do for them. But we can try. We have to try. If we don't, we're not > doing our users justice... > >> >> Sorry, I don't see any kind of indication that putting things in the >> manual is going to show "the gravity of the situation" any more than >> the deprecated errors will. > > > Again, I'm not limiting it to the manual. The manual is the "reference" > point for proving that it's deprecated, but it needs to be a community > effort, similar to how GOPHP5 was... > >> >> We're not discussing introducing new features here. We're discussing >> the deprecation of old features. > > > Right, but you're quoting how projects like Wordpress don't use 5.4. And I > pointed out that it runs fine on 5.4, it just doesn't take advantage of > specific features. That people haven't upgraded their servers is another > point entirely... > > >> >> How are we ignoring anything in future planning by giving people what >> could potentially be several years before the extension is removed. In >> the mean time, we have E_DEPRECATED errors being thrown (again in PHP >> 5.5, which likely 95% of those CMS frameworks you mention that depend >> on ext/mysql won't ever upgrade to), and the necessary migration guide >> and warnings in the manual. > > > Those platforms will likely support 5.5. They have in the past. And they > will going forward. Saying 95% won't upgrade to is a non-argument. The users > may not, but the platforms will (especially the hosted ones, as recent > performance improvements and security updates alone will mandate it)... > > And you also hit on another big point. You are mentioning the adoption rate > of new versions. That it's abysmal. And that's very true. > > It's also a huge problem that I think we need to solve. And we can solve. By > limiting BC breaks. By communicating effectively. By listening to the > community, and interacting with them. By being proactive rather than > isolated from them. > > I don't want to ever hear the excuse that we can do something because it'll > be 5 years before "they" will be effected. That's the wrong attitude. It > just perpetuates the problem of slow adoption. We should instead be lowering > those barriers. And one of the best barrier-lowering tools is clear and > healthy communication. > >> We're leading people into a sane migration path that will never happen >> if all we do is confuse them by saying one thing in the manual and >> doing nothing in the code. Most people will probably just take that as >> a sign of "nothing has changed... just keep doing whatever you're >> doing" > > > I think going from "not recommended" to throwing notices all over the place > is worse. It's like blindsiding them. We should at least try to get the > message out in a controlled manner, with a hard plan that people can > understand. If they chose to ignore it, that's their problem. But we should > be the bigger project... > >> >> I'd rather see those warnings and have the information in the manual >> and urge those projects to start finding a suitable migration path for >> the next year or two than spend a year convincing myself that people >> will do anything about ext/mysql code just because we're telling them >> its deprecated in the manual. > > > I would as well. Next release. When they have had time to heed the warning. > >> >> I think you greatly under-estimate who reads the manual and who has >> the power to modify/affect these OSS frameworks/CMSs to move away from >> ext/mysql. > > > If I under-estimate anything, it's the history that core has had in relating > to the projects. For a long time it's been a very "us-vs-them" attitude (or > looked like it from the outside). Lately, better cooperation and > collaboration has been happening. I believe that the community can be > strengthened. And the first step of that is to trust and try to build that > interaction again. If those projects don't change, I don't want it to be > because of lack of what we did. I would rather it be that they ignored us. > And I would rather it be that we work together to protect them, rather than > seeing them as outside of the community, or as people who don't matter. > >> >> Only when they have tens of thousands of users breathing down their >> upstream's neck about getting warnings will there be some justifiable >> stake for those upstreams to start taking serious action. I believe >> the most popular ones like WP have already demonstrated they are >> heading in that direction now. > > > If they are, then so be it. But that doesn't mean that we shouldn't try... > > Anthony
People have been talking about and educating others about the deprecation of ext/mysql for quite some time now. I'm sure that it could be more clearly voiced from an official PHP Project stand-point, but we're down-playing the amount of education that has already gone underway here. I'd like to direct your attention to some actual hard evidence of how far back and how high up this education stretches... This is a talk from Adam Harvey where he mentions the upcoming deprecation of ext/mysql in January of 2012 (months before the soft-deprecation notices in the manual). http://www.youtube.com/watch?feature=player_detailpage&v=QnCd0rG4Fvo#t=867s This is a link from a popular PHP blog/podcast talking about the upcoming deprecation/removal of ext/mysql dating back to July of 2011 http://www.phpclasses.org/blog/post/153-The-Plot-to-Kill-PHP-MySQL-Extension.html Here's another one dating back to August of 2011 http://randomdrake.com/2011/08/02/php-developers-finally-deprecating-extmysql-in-favor-of-mysqli-or-pdo/ Here's a forum thread discussing the topic with discussion ranging from August of 2011 to May of 2012. http://x10hosting.com/forums/scripts-3rd-party-apps-programming/162529-php-begin-deprecation-ext-mysql-start-moving-your-development-pdo-now.html Google gives me over 500K results for the search phrase "php ext/mysql deprecation" I have over GBs of IRC logs dating back to 2006 and when looking at the last two years I see ##PHP on freenode and other PHP support channels on other networks encouraging the use of the newer mysqli/pdo extensions over ext/mysql extensively. Someone posted a ticket in the WP bug system in this thread and a twitter conversation (I believe it was Pierre) showing WP is taking action to move away from ext/mysql in the future (probably not the immediate future, but we're not removing it just yet anyway -- we've got years). Drupal seems to be already in that direction with Drupal 7/8 http://drupal.org/requirements ---- In summation: I agree with you that education is good and we should help ease others into it. I also think that with the deprecation warnings people will take it far more seriously. This only extends the amount of education we're offering, not lessens it. With that said I'm certainly just one man voicing their concern here. I think everyone is making fair points in particular places and there is a little to be learned from each and every one of them. I just wish that this leads to a reasonable compromise that satisfies everyone involved here (framework/cms guys, internals guys, the lower-level guys at the bottom of the chain that probably don't ever read this list but will hate life when ext/mysql finally gets removed)... everyone, really! :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
