Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:20362 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19026 invoked by uid 1010); 25 Nov 2005 10:49:53 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 19011 invoked from network); 25 Nov 2005 10:49:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2005 10:49:53 -0000 X-Host-Fingerprint: 217.160.175.43 p15119030.pureserver.info Linux 2.5 (sometimes 2.4) (4) Received: from ([217.160.175.43:57548] helo=chatserv.de) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 34/06-56276-05CE6834 for ; Fri, 25 Nov 2005 05:49:53 -0500 Received: (qmail 3411 invoked by uid 1040); 25 Nov 2005 10:49:50 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost with SMTP; 25 Nov 2005 10:49:50 -0000 Date: Fri, 25 Nov 2005 11:49:50 +0100 (CET) X-X-Sender: sas@chatserv To: Derick Rethans cc: internals@lists.php.net In-Reply-To: Message-ID: References: <7.0.0.16.2.20051124161240.0573e640@zend.com> <20051125034515.6fefa4e2@localhost.localdomain> <43867C6C.2010209@prohost.org> <20051125040950.26305e08@localhost.localdomain> <43869FC5.4060708@lerdorf.com> <20051125075501.79718ee6@localhost.localdomain> <1132903004.9936.25.camel@localhost.localdomain> <1086017308.20051125091648@marcus-boerger.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there) From: sascha@schumann.cx (Sascha Schumann) > It's definitely not the most elegant way, I agree there. But there was > also no sneaking as it was discussed months before, and it was actually > Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1. Then I have to ask both of you: why is there no mentioning in the release notes or the upgrading guide regarding "Date" being reserved for PHP now? The language/base library might want to reserve certain simple classnames for itself. That is its right. But: Doing so in a minor release is absolutely bad timing. It gets worde because there apparently has been _no_ documentation of the fact at all. How shall our users prepare themselves appropiately? I move that the class is renamed for the time being as to not conflict with existing codebases, and release 5.1.1 expediently. - Sascha