Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78768
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <3E2593DC-5755-48A6-8802-6F2FB3625778@ajf.me>
References: <CABRjmp-oqEVtX-igQWsr-JkFmitqxn4YsyJ=mnzyHCN9Kj7akA@mail.gmail.com>
	<CAH-PCH62GAecxC00aHgzgskG8zk58z1LBE1uBv81xtj6hRiy5w@mail.gmail.com>
	<3E2593DC-5755-48A6-8802-6F2FB3625778@ajf.me>
Date: Thu, 6 Nov 2014 09:00:51 +0700
Message-ID: <CAEZPtU5bdrgX3yfNZhPsWqrU6d5fw=vX78-iW=gx1jUJoeF8YA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>, Florian Margaine <florian@margaine.com>, 
	Ferenc Kovacs <tyra3l@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c313ace17b4a0507271011
Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks
From: pierre.php@gmail.com (Pierre Joye)

--001a11c313ace17b4a0507271011
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Nov 6, 2014 11:46 AM, "Andrea Faulds" <ajf@ajf.me> wrote:
>
>
> > On 5 Nov 2014, at 20:34, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> >
> > 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 mor=
e
> > 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 dolla=
r
> > 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.
> >
> > Just my 2 cents ofc.
>
> Hmm. Wouldn=E2=80=99t allowing minor BC breaks in minor versions be bette=
r 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?
>
> --

We have minor BC breaks (new errors. Slight behavior changes due to bug
fixes).

But globally no, it makes end users work harder for migration, even worst
for distros.

See Debian f.e., they boost the adoption speed now, we finally see some
results, within the 2-4 years plan we had back then. I could not imagine a
worst time to rollback what we defined.

--001a11c313ace17b4a0507271011--