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 <ircmax...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
