Re: RFCs should mention all BC breaks (was Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes())

Am 25.09.2019 um 03:47 schrieb Pierre Joye <pierre.php@gmail.com>: > 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 === 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