Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78785
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.53 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 07:49:57 +0100
Message-ID: <CAH-PCH4hJj=KqxXSUAP7mXC4NAJF=CXqTHV1vesG0-8WXvocdw@mail.gmail.com>
To: Andrew Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>, Florian Margaine <florian@margaine.com>
Content-Type: multipart/alternative; boundary=001a11c30504bfc65105072b1a84
Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c30504bfc65105072b1a84
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014.11.06. 2:46 ezt =C3=ADrta ("Andrea Faulds" <ajf@ajf.me>):
>
>
> > 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?

With major versions you have years to migrate(while we don't cover this in
our release process rfc, but we tend to keep the previous major version
alive for years) but I do agree that more frequent but smaller BC breaks
are better, but I would use that as an argument for having smaller but more
frequent majors. Like a new major version every 3 years where we provide
support 2years standard and 1 year security support, so we always have 2
major branches active, but never have more than two minor versions for a
major.
But this probably needs a bit more thought.

--001a11c30504bfc65105072b1a84--