Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78767
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAH-PCH62GAecxC00aHgzgskG8zk58z1LBE1uBv81xtj6hRiy5w@mail.gmail.com>
Date: Thu, 6 Nov 2014 01:46:45 +0000
Cc: Florian Margaine <florian@margaine.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3E2593DC-5755-48A6-8802-6F2FB3625778@ajf.me>
References: <CABRjmp-oqEVtX-igQWsr-JkFmitqxn4YsyJ=mnzyHCN9Kj7akA@mail.gmail.com> <CAH-PCH62GAecxC00aHgzgskG8zk58z1LBE1uBv81xtj6hRiy5w@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks
From: ajf@ajf.me (Andrea Faulds)


> On 5 Nov 2014, at 20:34, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>=20
> Regardless of those, I think it would be worse from the users POV than =
our
> current policy where we target no BC breaks in minor/micro versions.
> The only exception should be security concerns (see the unserialize =
changes
> in 5.6 for such an example), which shows that usually BC breaks are =
more
> about the tradeoff, having a BC for a cornercase which probably nobody =
will
> notice but it will simplify the langspec/parser is a different kind of =
BC
> that switching the needle/haystack argument order or removing the =
dollar
> sign would cause.
> Trying to compare or quantify those are hard, and they should be =
decided on
> their own merrit not how much open slot do we have.
>=20
> Just my 2 cents ofc.

Hmm. Wouldn=E2=80=99t allowing minor BC breaks in minor versions be =
better than having BC breaks only in majors? Is it not easier to make =
one or two small code changes each year, than to do a massive migration =
every 5 years?

--
Andrea Faulds
http://ajf.me/