Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90974 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36386 invoked from network); 27 Jan 2016 09:28:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jan 2016 09:28:35 -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:53997] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 24/B6-28185-2CD88A65 for ; Wed, 27 Jan 2016 04:28:35 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 08383785405; Wed, 27 Jan 2016 10:28:31 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) 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=unavailable autolearn_force=no version=3.4.0 Received: from w530phpdev (p579F3836.dip0.t-ipconnect.de [87.159.56.54]) (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 012C6785402; Wed, 27 Jan 2016 10:28:29 +0100 (CET) To: "'Yasuo Ohgaki'" Cc: "'Stanislav Malyshev'" , "'Remi Collet'" , , "'Yasuo Ohgaki'" References: <03a501d15439$fcbf9ca0$f63ed5e0$@php.net> <56A1054A.5080102@fedoraproject.org> <56A2069B.2050007@fedoraproject.org> <56A21D68.6030403@fedoraproject.org> <56A825A9.9020706@gmail.com> <56A85967.4090603@gmail.com> <01c101d158d9$a0533450$e0f99cf0$@belski.net> In-Reply-To: Date: Wed, 27 Jan 2016 10:28:26 +0100 Message-ID: <01d001d158e5$157f14a0$407d3de0$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHsl++e30t/kLKxuC36hZ0/YzeBFQIq8uRuAYbF2n8BtZ3tHgEw+119AcPWaWACq7463QJG1BqXAfA9AHQCvCEp2AE8PREhnj7XXUA= Content-Language: en-us Subject: RE: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break *** From: anatol.php@belski.net ("Anatol Belski") Hi Yasuo, > -----Original Message----- > From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo > Ohgaki > Sent: Wednesday, January 27, 2016 9:19 AM > To: Anatol Belski > Cc: Stanislav Malyshev ; Remi Collet > ; internals@lists.php.net; Yasuo Ohgaki > > Subject: Re: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** = BC break *** >=20 > Hi Anatol, >=20 > On Wed, Jan 27, 2016 at 5:06 PM, Anatol Belski = wrote: > > Thanks for all the investigation (as well Remi, Stas and everyone). = At first > glance last week, as for me, it looked like OK to keep at least the = 7.0 part, as the > breach was only concerning the unit tests but unlikely the actual web > functionality. While it is good to have improvements and hardening on = the > unclean behaviors, the area is critical and should be kept stable in = stable > branches. Right now, it seems that the patch can have unexposed = impacts. > > > > I would like also to remind that we're now quite short in time as = finals are > planned for the next week. With this in mind, IMHO it's better to play = safe and > revert 5.6 and 7.0 to the previous state before this change. Or at = least, don't > release these patches in the upcoming finals, but keep improving and = fixing BC > breaches in dev branch and re-evaluate the status in the next possible = RC. >=20 > Reported unit test failures were test code is finding bug fix logic = changes. There > are missing "if" for transid, but other than this, these changes are = valid and > correct. >=20 > However, as a user stand point view, it's frustrating unit tests fails = on new minor > version, even if it is due to proper fixes. >=20 > I agree to postpone the fix to next minor version up. Shall I revert = my patches > now? >=20 If you're willing to work on fixing BC breaches till next minor RC, it = might be the way to proceed. If on the next RC we see no signs of = regression, so we could take it into the next minor. Otherwise, if we = see that there are still doubts on stability, we could stop trying to = bring those changes in a stable branch but go for master. Yasuo, it's = really up to your willingness to spend time on stabilizing, maybe also = checking the Horde tests where the issues was initially discovered, and = being aware of possible risk that it possibly wouldn't make it into = stable. Anyways for the upcoming final, releasing your patches seems = risky. If we're aware, maybe that were the way to go. At least this were my = suggestion, as Ferenc haven't finished his review yet. Let's wait for = him and have the final decision. Thanks Anatol