Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78652 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71788 invoked from network); 4 Nov 2014 17:27:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Nov 2014 17:27:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:50789] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CD/1B-06676-C7C09545 for ; Tue, 04 Nov 2014 12:27:25 -0500 Received: (qmail 7375 invoked by uid 89); 4 Nov 2014 17:27:21 -0000 Received: by simscan 1.3.1 ppid: 7359, pid: 7372, t: 0.1693s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.163.79.60) by mail4.serversure.net with ESMTPA; 4 Nov 2014 17:27:21 -0000 Message-ID: <54590C78.2020402@lsces.co.uk> Date: Tue, 04 Nov 2014 17:27:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: PHP internals References: <5458CEAF.7060204@lsces.co.uk> <5458D492.9040207@lsces.co.uk> <5458E306.50006@lsces.co.uk> <5458F9DA.7060308@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Debugging code ... From: lester@lsces.co.uk (Lester Caine) On 04/11/14 16:25, Chris Wright wrote: > An 18 month release cycle for minors and over a decade since the last > major is hardly "daily". You do not need to update the libraries when > they start to use the new language features, but if you want to use the > new library features, and those features leverage new language features, > then you need to update the runtime as well. If you don't want/need the > shiny new features, just don't upgrade. PHP is hardly the only ecosystem > where this is true... It is not the PHP infrastructure which is the problem here ... it is everything else that PHP relies on to get it's output to the end user. I've had two updates today on Firefox (and one has broken new tab function!), and most of the legacy sites have had to have some changes to make them work cleanly with 'modern browsers'. But even in the PHP domain, PHP5.3 and 5.4 can hardly be called minor updates. The both require substantial work to ensure sites remain working after an upgrade. phpng is the sort of major upgrade we ARE all looking for, and was originally road mapped as not affecting the core language? That is making PHP better, and there ARE ports of PHP with their own take on how things should change language wise? All I am asking is that consideration is given to the full effect on backwards compatibility by some of the non-essential changes. 'Does not have' is often an incorrect statement when you widen the pool of resources and we should be contesting those claims anyway. The point about the debuggers was that THEY do exist as separate tools and I think some of the other features being requested would also work better as separate tools. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk