Re: RFC: ext/mysql deprecation

From: Date: Fri, 16 Nov 2012 01:16:34 +0000
Subject: Re: RFC: ext/mysql deprecation
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-63899@lists.php.net to get a copy of this message
On 14/11/12 03:17, Adam Harvey wrote: > On 14 November 2012 00:07, Anthony Ferrara <ircmaxell@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

« previous php.internals (#63899) next »