Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61952 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74765 invoked from network); 2 Aug 2012 08:40:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2012 08:40:28 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.127 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 213.123.20.127 c2bthomr09.btconnect.com Received: from [213.123.20.127] ([213.123.20.127:58155] helo=mail.btconnect.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D3/44-48311-AFC3A105 for ; Thu, 02 Aug 2012 04:40:27 -0400 Received: from host81-138-11-136.in-addr.btopenworld.com (EHLO _10.0.0.5_) ([81.138.11.136]) by c2bthomr09.btconnect.com with ESMTP id IPQ19756; Thu, 02 Aug 2012 09:40:23 +0100 (BST) Message-ID: <501A3CF4.1030602@lsces.co.uk> Date: Thu, 02 Aug 2012 09:40:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10 MIME-Version: 1.0 To: PHP internals References: <1343826814.77002.YahooMailNeo@web133004.mail.ir2.yahoo.com> <50197263.6060905@gmail.com> <50197934.5060005@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.501A3CF5.00ED, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.8.2.81517:17:7.944, ip=81.138.11.136, rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __HAS_FROM, __USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __CT, __CT_TEXT_PLAIN, __CTE, __ANY_URI, __URI_NO_MAILTO, __URI_NO_WWW, __CP_URI_IN_BODY, BODY_ENDS_IN_URL, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.501A3CF7.01DF:SCFSTAT14830815,ss=1,re=-4.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates From: lester@lsces.co.uk (Lester Caine) Adam Harvey wrote: > Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or > would we rather have a manual array?) Specific notes on > vulnerabilities to add to branches? Better versions of the copy in the > initial blurb? A little academic now, but I was convinced that 5.1 had some more official releases? 5.1.6 had a number of bugs that prevent Firebird/Interbase working and we had 2.1.7 running which fixed the problem. Was that never released officially? Academic as I say, and everything was moved to 5.2 quite quickly as it rolled out without any problems and removed some of the problems created by 5.1 itself - such as the date code clashes ;) Can I make a request for an additional column which links to the relevant migration guide. That would at least be a start, but I'm currently trying to work through 5.3 and 5.4 migration guides to see if they DO have fixes for the 'problems' that are coming up on porting code from PHP5.2 ... The statement "Most improvements in PHP 5.3.x have no impact on existing code." should perhaps be augmented with a least some reference to ensuring that the .ini settings are compatible with PHP5.2 code? Is there a document that shows what settings .ini should have to maintain compatibility? I could not find anything suitable although everything is documented somewhere. I think one thing that is preventing many ISP's switching is the removal of register_globals ? Heck *I* still have code which will not work without register_globals and the time it would take to rework that code is just another job I don't have time for :( The fact that 5.3 still supports this is given as the reason for not switching to 5.4 just yet. Not a problem for this list perhaps, but many of the end users probably have no idea how to fix this particular problem as they are using third part code that relies on it? -- 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