Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71943 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75192 invoked from network); 1 Feb 2014 21:14:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Feb 2014 21:14:39 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.123 smtp123.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.123] ([108.166.43.123:56676] helo=smtp123.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 71/97-30967-EB36DE25 for ; Sat, 01 Feb 2014 16:14:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2709F1A0157; Sat, 1 Feb 2014 16:13:41 -0500 (EST) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id B8C0A1A0150; Sat, 1 Feb 2014 16:13:40 -0500 (EST) Message-ID: <52ED6383.1010800@sugarcrm.com> Date: Sat, 01 Feb 2014 13:13:39 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Zarkos , PHP Internals References: <1391171792.2941.130.camel@guybrush> <52EB9A16.5060605@phpdoc.de> <1391172906.2941.140.camel@guybrush> <9810c708a9fcc543a263365b5d7c2a63@mail.gmail.com> <52ECF62A.5060401@lsces.co.uk> <8342d52536b143739928e0a533c750fe@BY2PR03MB060.namprd03.prod.outlook.com> In-Reply-To: <8342d52536b143739928e0a533c750fe@BY2PR03MB060.namprd03.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length and integer From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > There is no PHP 6. If there was this RFC would have had two simple > options; merge for PHP 6.0, merge for both 5.6 & 6.0. The > justification for the latter option being that 5.6+ would provide a > more reasonable upgrade path for 6. It may not be meant this way, > but suggesting we merge this into PHP6 simply sounds disrespectful. > There's no point in targeting some ethereal release, that's just a > way of kicking this down the road so it can be ignored for a little > longer. Without a plan forward to a release, even merging to Master > is just another place for this to languish. There is no PHP 6, that is true. But there will be, unless we consider this patch a good way to close the project and go home. I hope nobody thinks that way. Thus, there will be PHP 6. And not as some pie in the sky, but as a next version, which needs to happen. Yes, we do not have a release plan or roadmap for it yet. But I think we realize the need for it and we can work on it. If this does not happen, we can also realize it did not happen in time for bringing this patch in for 5.7 - *with* the knowledge that PHP 6 is not realistic anymore, knowledge that we do not have now. I do not see how it is disrespectful to suggest a high-risk change should be happening in a major version which is supposed to cause major breakage. You may agree or disagree but this has nothing to do with respect. I can't speak for others but I can speak for myself in saying that these concerns are not just kicking the can down the road in hope that eventually this patch dies off. This is a real and genuine concern about the disruption caused and I actually do want this to happen - just not in a way that would make 5.6 the release to never use for a huge set of customers. > And yes, I know there has been some (hopefully) serious discussion > on PHP6 recently, but that happens every year. Maybe it will happen > this time? IMHO, if PHP 5 has slipped happily into middle age and > cannot fathom such change anymore, then perhaps this community > should create a roadmap to a new branch where more progressive > development can be realized. This branch is exactly what we're talking about when we're talking of PHP 6. We must realize that we have dual responsibility here, with both progress and existing base support being at least equally important, arguably the latter even more important, even if less glamorous. Thus, we have to maintain the balance. And if we have big changes that are necessary, then it may be actually make that revolutionary branch be more than just talk. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227