On Mon, Aug 22, 2016 at 6:30 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote:
> On 22.08.2016 at 18:00, Julien Pauli wrote: > > > I agree this is a BC break and should not stay as-is in source code. > > I wonder why we have more than 100 lines of "Backward incompatible > changes" in the PHP 7.1.0beta3 changelog[1], if BC breaks shouldn't be > introduced in a minor release. > That's a bit loaded question, and leads to a broken windows situation, but from my understanding some people read https://wiki.php.net/rfc/releaseprocess differently: consider some BC breaks simply bug fixes, or think that we shouldn't stick to absolutes but consider BC breaks on a case-by-case basis. personally I think tha > > > It makes some testsuites fail, that did not fail before ; thus it breaks > things. > > An estimated 10% (at least) of my *bugfixes* in GD broke at least one > PHPT, because the test was broken in the first place. > test failures can be false positive or depending explicitly undefined behaviors, but they can be a good indicator when looking for BC breaks. as we can see from the previous mails in this thread there are behavior changes where the previous behavior was different from what was documented so a bit of a grey area. personally I think that we are in general too lenient with allowing BC breaks in 7.1 (even though that I somehow expected this and was arguing for a longer release cycle for 7.0 or at least having a clear roadmap for the next major version) and we should be more strict about it otherwise we will lose the trust we gained from the userland in the last couple of years with our release process and versioning. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
