Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:40393 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47628 invoked from network); 9 Sep 2008 05:15:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Sep 2008 05:15:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=greg@chiaraquartet.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=greg@chiaraquartet.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error) X-PHP-List-Original-Sender: greg@chiaraquartet.net X-Host-Fingerprint: 208.83.222.18 unknown Linux 2.6 Received: from [208.83.222.18] ([208.83.222.18:51779] helo=mail.bluga.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 26/C5-14433-67606C84 for ; Tue, 09 Sep 2008 01:15:35 -0400 Received: from mail.bluga.net (localhost.localdomain [127.0.0.1]) by mail.bluga.net (Postfix) with ESMTP id 8ACC5C0DDDF; Mon, 8 Sep 2008 22:14:48 -0700 (MST) Received: from Greg-Beavers-monster.local (CPE-76-84-4-101.neb.res.rr.com [76.84.4.101]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bluga.net (Postfix) with ESMTP id EB2E6C0DDDC; Mon, 8 Sep 2008 22:14:47 -0700 (MST) Message-ID: <48C60671.4040608@chiaraquartet.net> Date: Tue, 09 Sep 2008 00:15:29 -0500 User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807) MIME-Version: 1.0 To: Lester Caine CC: PHP Developers Mailing List References: <48C5F612.6090001@lsces.co.uk> In-Reply-To: <48C5F612.6090001@lsces.co.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: 5.3 Backwards Compatibility From: greg@chiaraquartet.net (Greg Beaver) Hi Lester, Lester Caine wrote: > While I have loaded 5.3.? changing any of my existing code base to > remove warnings is not likely to happen any time soon since > compatibility with users who are still running older versions of PHP > still needs to be maintained. > > I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be > currently the only reference to changes? But where do I find the detail > on how things ARE currently implemented such as namespace and (fingers > down throat) goto? the manual is ridiculously up to date, and is the best reference location for new features. Occasionally things are documented within seconds of commit and in one case *prior* to commit. It's frightening what they do :). > Another major concern here since maintaining BC with *PHP4* is still an > unfortunate current requirement in the field is what happens when PEAR > actually uses namespace and other 5.3 only features. HOW will we manage > accessing versions of PEAR that are compatible with our active codebase > and so ensure that we have compatible sets of packages? This and the following paragraph are questions for PEAR, and don't concern internals developers, pear-dev@lists.php.net is the best list for tech questions like the ones you raise. However, I will say that PEAR has been doing just fine with the handling of PHP version differences to date. The installer is fully aware of PHP version dependency, and refuses to install packages that are incompatible with your PHP version. If you find an older package that has an incompatibility with a newer PHP version, this is considered a bug in the package that must be fixed (again, a PEAR problem, not a PHP problem). However, if you upgrade PHP, it is best to upgrade the existing packages to be sure you have ones compatible with the current PHP release. This is a tricky problem, but fortunately the most-used PEAR packages are carefully tracked against PHP releases by their maintainers, so we have not had a PHP version-related problem since the move to 5.0. > Personally I can't stand the CURRENT problems that is caused by not > knowing which version of a PEAR extension users actually have and in > order to ensure a COMPATIBLE version, but in future will the PEAR > installer pick up a correct version for the copy of PHP actually being run? "pear list" show the version information you need, and PEAR since version 1.6.0 takes into account PHP version prior to download (1.6.0 was released June 7, 2007) > I get the distinct impression that those pushing for PHP5.3 are simply > not making a good case for many of us to even want to follow them down > that path? It almost feels like this is a DIFFERENT path to the main > stream of PHP6 which many of us are much more desperate to be testing in > the field, which seems to have become an ignored backwater? Key elements > which have been flagged to PHP6 ( such as BIGINT ) are on hold while new > concepts which were not part of the PHP6 reoadmap have been forced > through? Since current hardware *IS* 64 bit, actually handling 64 bit > numbers properly would be nice :) I think I have made an excellent case for the things that I care about in 5.3. ;) Greg