Or you as a developer add the following to your code: error_reporting(error_reporting() & ~E_NOTICE);
at the top of a common file and release a new release and quit f***ing b****ing about something which isn't likely to change anytime soon. If your clients aren't knowledgeable enough to setup their servers properly to not show errors in a production environment, then do it for them in your script. Yeah it's not the best solution, but it works fine and gives you time to correctly update your scripts the proper way. -Jeremy On 7/17/05, Jon Parise <[EMAIL PROTECTED]> wrote: > On Tue, Jul 12, 2005 at 10:33:14PM +0100, Nicholas Telford wrote: > > > Firstly, a major version number increment implies a major change (4.2.0 > > and 4.3.0 had much more major changes than this iirc). Secondly, as far > > as I'm aware, it doesn't issue a warning, it issues notices which, and > > this has been stressed on many occasions, should not be displayed on > > production servers. > > Sure, but the issue here has very little to do with production > servers. > > What's happening is that site administrators are upgrading their test > environments and then checking their existing software to make sure it > hasn't broken. They see all of these new warnings and then report > them back to the application developers. It would be much easier for > each application developer to redirect that site administrators to a > note on php.net explaining the change than for the application > developers to explain the change over and over again. Or, even > better, the administrator would find it there themself. > > -- > Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/) > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- --------------------------- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
