Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107319 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66562 invoked from network); 25 Sep 2019 12:35:22 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 25 Sep 2019 12:35:22 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id A79262C0497 for ; Wed, 25 Sep 2019 03:14:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15623 62.12.128.0/17 X-Spam-Virus: No Received: from mail.gna.ch (darkcity.gna.ch [62.12.172.119]) by php-smtp3.php.net (Postfix) with ESMTP for ; Wed, 25 Sep 2019 03:14:28 -0700 (PDT) Received: from [10.0.1.55] (77-56-180-37.dclient.hispeed.ch [77.56.180.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 7FA5720ECC; Wed, 25 Sep 2019 12:14:27 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: Date: Wed, 25 Sep 2019 12:14:26 +0200 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <696dc114-c2df-40aa-aad6-5b87d4373c0e@www.fastmail.com> <83A8831C-1570-4E62-BF37-06774C5FB26D@cschneid.com> To: Pierre Joye X-Mailer: Apple Mail (2.3445.104.11) X-Envelope-From: Subject: Re: [PHP-DEV] RFCs should mention all BC breaks (was Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes()) From: cschneid@cschneid.com (Christian Schneider) Am 25.09.2019 um 03:47 schrieb Pierre Joye : > The question is also about what is a BC break, f.e is changing error = level a BC break? or the return value on error? This seems to be a complicated question but I think if we boil it down = to a guideline instead of a hard rule it is not that hard after all. My personal view is this: Changing error levels is certainly an edge case: No, the code does not = have to be changed to get the same result. Yes, they can output = additional error messages (hopefully to a log file, not stdout) which = may need to be filtered. But I'd still think that's a very minor change = and is less important. When the control flow of the program for well-defined behaviour changes, = that's when previously working code breaks. - Changing a notice/warning to an exception is a BC break as it needs = different code to handle it. - Return values on error is a BC break as code trying to properly handle = errors has to be changed (e.g. strpos =3D=3D=3D false breaks if the = error return value is changed to null). This doesn't mean such changes cannot be done but there should be a = consensus that it is worth it IMHO. An broad agreement on what is and what isn't a BC break would be useful. = It doesn't have to cover everything but getting on the same page for = stuff like the above might help reduce friction when discussing changes. - Chris