Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:30532 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21469 invoked by uid 1010); 6 Jul 2007 16:06:58 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 21454 invoked from network); 6 Jul 2007 16:06:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jul 2007 16:06:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=antony@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=antony@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender) X-PHP-List-Original-Sender: antony@zend.com X-Host-Fingerprint: 212.25.124.162 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from [212.25.124.162] ([212.25.124.162:17414] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9F/E6-50692-F986E864 for ; Fri, 06 Jul 2007 12:06:58 -0400 Received: (qmail 10102 invoked from network); 6 Jul 2007 16:06:52 -0000 Received: from internal.zend.office (HELO ?127.0.0.1?) (10.1.1.1) by internal.zend.office with SMTP; 6 Jul 2007 16:06:52 -0000 Message-ID: <468E689A.4030302@zend.com> Date: Fri, 06 Jul 2007 20:06:50 +0400 User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Rasmus Lerdorf CC: Derick Rethans , PHP Developers Mailing List References: <468E5AB1.3080308@lerdorf.com> <468E5E3B.5090408@zend.com> <468E66B2.3060903@lerdorf.com> In-Reply-To: <468E66B2.3060903@lerdorf.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RIP PHP 4? From: antony@zend.com (Antony Dovgal) On 06.07.2007 19:58, Rasmus Lerdorf wrote: >> To me it means in the first place that we can add a canned answer to the >> bugtracker which would say "PHP4 is not supported anymore, install PHP5" >> and close all PHP4 only reports. >> >> So no bug-fixes, no releases except for ones fixing critical security >> problems. >> And even that should be ceased either in say.. 1 or 2 years. > > When was the last time we did a PHP4-only bug fix? Doesn't matter, we still have many of PHP4-only reports which nobody is going to look in anyway. Also it wasn't that long ago: - Fixed bug #38798 (OpenSSL init corrected in php5 but not in php4). (Tony) > My fear is that the impact of the no-more-support statement is hurt when > we qualify it with the fact that nothing is really changing. Well, I explained what should change in the first place - no more PHP4 reports. If you're unable to reproduce it with PHP5 - sorry, we can't help you. > I'd be more in favour of a statement that put a final death date on it > which means no new releases of any sort. We could still say > security-fixes only by the end of the year and then death by 08/08/08 or > something like that. Yup, that's exactly what I said in my e-mail. -- Wbr, Antony Dovgal