Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66427 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11878 invoked from network); 2 Mar 2013 20:48:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Mar 2013 20:48:08 -0000 X-Host-Fingerprint: 217.114.211.68 unknown Date: Sat, 02 Mar 2013 15:48:06 -0500 Received: from [217.114.211.68] ([217.114.211.68:25964] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0C/CE-30973-68562315 for ; Sat, 02 Mar 2013 15:48:06 -0500 To: internals@lists.php.net References: <435a322ccb14090d3bcf6bf8a110396d@mail.gmail.com> <-8565214987830661092@unknownmsgid> User-Agent: slrn/0.9.9p1 (SunOS) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-Posted-By: 217.114.211.68 Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution From: dsp@php.net (David Soria Parra) On 2013-02-27, Zeev Suraski wrote: > On 27 ???? 2013, at 18:58, Anthony Ferrara wrote: > >> Zeev et al, >> >> I just want to put my justification for the "only if no delay" vote. I voted that way because we're already at a significant delay. If this vote was a month ago when O+ was suggested first, I would definitely have voted for "delay". In fact IIRC I proposed a delay back then. But after a month, I think delaying much further would be imprudent. >> > > Fair enough! Here's mine for delaying: > > I believe our users will much appreciate a release with an opcode > cache that's several months delayed vs. one that's without an opcode > cache several months early. If the 5.4 adoption rate (or complete > lack thereof) is any indication - very few are eagerly waiting for > 5.5. In fact, in a year's time, when we all gear up to release 5.6 > (based on current frequency) - 5.5 is almost guaranteed to have next > to no traction in our userbase. A bundled opcode cache might be the > killer feature that makes the difference. I agree with zeev here. The opcode cache is one of the most important thing for adoption. With apc not being 5.4 compatible and 5.3 eol with 5.6, there is no real transition for people relying on an opcode cache if we don't delay 5.5. That's the only reason why Julien and I so far delayed it.