Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95416
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <dd455ef8-d02f-9e7f-94ba-8e276bce2688@gmx.de>
References: <CAEbg-4ZAMB=Em-nwCp++K3n59btaFSgW-yexhg3cbM3bQ1WjTg@mail.gmail.com>
 <CAMUwpuQe1bS1D9KVRKkqd7-jXw8sx_mWUDrxDjX=i9J5LQSnwg@mail.gmail.com> <dd455ef8-d02f-9e7f-94ba-8e276bce2688@gmx.de>
Date: Tue, 23 Aug 2016 17:03:51 +0200
Message-ID: <CAH-PCH6zmgF34oEEXjvkD7k6z79dwLA81=UbjuekT3BNkst+2Q@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Julien Pauli <jpauli@php.net>, Alexander Lisachenko <lisachenko.it@gmail.com>, 
	Rowan Collins <rowan.collins@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141004006eb03053abe79e8
Subject: Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter1
 to be object, string given
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a1141004006eb03053abe79e8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 22, 2016 at 6:30 PM, Christoph M. Becker <cmbecker69@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 break=
s
> 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.



--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a1141004006eb03053abe79e8--