On 14/11/12 03:17, Adam Harvey wrote: > On 14 November 2012 00:07, Anthony Ferrara <ircmax...@gmail.com> wrote: >> There's one important thing that I think you all are missing here. You keep >> bringing up that we should just use the normal "deprecation" process. The >> problem is that the deprecation process was never designed for a feature >> like this. > Serious question: what was it designed for, then? This (along with > magic quotes, and register globals) was always what I had in the back > of my mind when it was being discussed. > > <snip>
There are two big differences here. The first is that ext/mysql is still *very* widely used. Secondly, the deprecation process (throwing deprecation warnings, then removal) should not be applied to *extensions* anyway. Magic quotes and register globals were PHP engine features. There was no other "user friendly" way to get rid of them, because once gone, it's gone. (Ok, they could have maybe been made into an extension, but nobody wanted that anyway...). The deprecation process here should similar to the process used for other extensions that have been retired/removed from core (Crack, mhash, sybase, ming, msql, fdf, fbsql, dbase, filePro, Hyperwave, etc) 1. Add "remove from core" status in documentation with notice about maintenance dropping after 5.next 2. Remove it from core (those who still need it can pull from PECL) 3. If the community needs it after 5.next, then they'll have to step up and maintain it themselves. The point is, an extension should never be throwing deprecation warnings for a planned migration to PECL. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
