Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88758 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 42163 invoked from network); 12 Oct 2015 22:15:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Oct 2015 22:15:16 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:49097] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7C/B3-16518-3F03C165 for ; Mon, 12 Oct 2015 18:15:16 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id B3DFD6D2002; Tue, 13 Oct 2015 00:15:12 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on h1123647.serverkompetenz.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.5 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=ham version=3.3.2 Received: from w530phpdev (pD9FE8C81.dip0.t-ipconnect.de [217.254.140.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id ADDC223D6185; Tue, 13 Oct 2015 00:15:10 +0200 (CEST) To: "'Dmitry Stogov'" , "'Nikita Popov'" Cc: "'PHP internals'" References: <01f001d1052b$bed5cbb0$3c816310$@belski.net> In-Reply-To: Date: Tue, 13 Oct 2015 00:15:07 +0200 Message-ID: <022501d1053b$75d68f20$6183ad60$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHOk30Kiw4kfjy5GlDIeoGWC6GzkgIHObdwAQHL6M0CAeBVJQIEEeh7AiYMMSueI6b5QA== Content-Language: en-us Subject: RE: [PHP-DEV] Re: Forbid rebinding scope of closures created by ReflectionFunctionAbstract::getClosure() From: anatol.php@belski.net ("Anatol Belski") > -----Original Message----- > From: Dmitry Stogov [mailto:dmitry@zend.com] > Sent: Monday, October 12, 2015 11:55 PM > To: Nikita Popov > Cc: Anatol Belski ; PHP internals > > Subject: Re: [PHP-DEV] Re: Forbid rebinding scope of closures created = by > ReflectionFunctionAbstract::getClosure() >=20 > On Mon, Oct 12, 2015 at 11:32 PM, Nikita Popov > wrote: >=20 > > On Mon, Oct 12, 2015 at 10:22 PM, Anatol Belski > > > > wrote: > > > >> Hi, > >> > >> > -----Original Message----- > >> > From: Nikita Popov [mailto:nikita.ppv@gmail.com] > >> > Sent: Monday, October 12, 2015 8:57 PM > >> > To: Dmitry Stogov > >> > Cc: PHP internals ; Andrea Faulds > >> > ; > >> Stas > >> > Malyshev ; Bob Weinand ; > >> > Anatol Belski > >> > Subject: [PHP-DEV] Re: Forbid rebinding scope of closures created > >> > by > >> > ReflectionFunctionAbstract::getClosure() > >> > > >> > > It would be great, if we stop any commits into PHP-7.0 except = for > >> > critical fixes now > >> > > >> > Maybe keep PHP-7.0 open (or as open as release branches usually > >> > are), > >> but from > >> > now on only cherry-pick critical fixes into PHP-7.0.0 (instead of > >> merging > >> > everything)? > >> > > >> I commit myself to Dmitry's words. What matters today and = especially > >> after RC5 is the stability. Today we should invest into testing and > >> bug fixes more than into improvements (aka fixes to something that = is > >> not broken). It really matters for the quality of the final. That's > >> the message to convey probably. > >> > > > > To rephrase my question: Should we treat PHP-7.0 the same way we = treat > > PHP-5.6 and other release branches (i.e. all kinds of bug fixes are > > okay, even if it's just improving a test or fixing some > > inconsequential behavior), or do you want to limit the PHP-7.0 = branch > > to actually critical fixes now? From what you say, I assume the = former rather > than the latter? > > >=20 > Of course, we should merge bug fixes from PHP-5.6. > Delaying them by month will make more overhead for everyone. > But the less changes we will get the better. >=20 Yeah, the git workflow persists. Of course, it can potentially introduce = instabilities. Then cherry-picking is not to sidestep, so in worst case = there is a solution anyway. Regards Anatol