On Fri, Nov 16, 2012 at 10:09 AM, Lester Caine <les...@lsces.co.uk> wrote:
> Rasmus Lerdorf wrote: > >> We need a frontpage notice. A big notice in the next UPGRADING file. >> There was nothing about this in the 5.4 UPGRADING file, for example. We >> also need tutorials showing how to migrate from mysql to mysqli and >> conference talks on the same showing some of the cooler things like >> async queries that you get by moving to a more modern API. >> > > This sounds like a much more realistic approach to the problem. The only > way that E_DEPRECATED would work practically is if it was a separate > E_MYSQL_EOL since there are other more important warnings that would be > hidden simply to maintain mysql? But it's not just migration tutorials that > are lacking, we STILL need some good quality PHP5.4 style guides! Showing > how to migrate from pre PHP5.2 style working ... In terms of deprecation schedule, I agree with Pierre's earlier comment that we should start throwing E_DEPRECATED as early as 5.5 or 5.6, then support should just be dropped entirely in 6.0. I'm a big proponent of the idea that BC should be less of a concern for major version increments. There is something really important I'd also like to stress: In UPGRADING, as well as any other literature we release designed to help people with this transition, we should not simply focus on porting ext/mysql code to mysqli. We should emphasize the use of prepared statements and fully integrate that into any tutorials we put out there. There are too many PHP devs out there who don't even know what prepared statements are and their ported mysqli code will reflect this if we're too lax on this point. Rasmus is right about asynchronous queries and other features being really helpful as well, but I think prepared statements stand apart because they prevent what is currently one of the most common security vulnerabilities on the web today. I'd like to see any tutorials we write just make conversion to prepared statements part of the porting process; it shouldn't even be framed as optional. A lot of devs will probably just run down the list step-by-step, so I think it would be best to make sure one of those steps involves converting query parameters to prepared statements. I'm not sure if somebody's already committed to writing these docs yet, but either way I'd be happy to lend a hand with that. --Kris
