Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78792
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH4hJj=KqxXSUAP7mXC4NAJF=CXqTHV1vesG0-8WXvocdw@mail.gmail.com>
References: <CABRjmp-oqEVtX-igQWsr-JkFmitqxn4YsyJ=mnzyHCN9Kj7akA@mail.gmail.com>
	<CAH-PCH62GAecxC00aHgzgskG8zk58z1LBE1uBv81xtj6hRiy5w@mail.gmail.com>
	<3E2593DC-5755-48A6-8802-6F2FB3625778@ajf.me>
	<CAH-PCH4hJj=KqxXSUAP7mXC4NAJF=CXqTHV1vesG0-8WXvocdw@mail.gmail.com>
Date: Wed, 5 Nov 2014 23:53:58 -0800
Message-ID: <CAKOpQSwrpgkvFB_qvs+PTmSLvzJdBYKFSq6pzogugE1zQxL4Ng@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Andrew Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>, 
	Florian Margaine <florian@margaine.com>
Content-Type: multipart/alternative; boundary=001a11c30504bc089905072bff8f
Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks
From: kris.craig@gmail.com (Kris Craig)

--001a11c30504bc089905072bff8f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 5, 2014 at 10:49 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

> 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 tha=
n
> 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 nobod=
y
> will
> > > notice but it will simplify the langspec/parser is a different kind o=
f
> 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.
> > >
> > > Just my 2 cents ofc.
> >
> > Hmm. Wouldn=E2=80=99t allowing minor BC breaks in minor versions be bet=
ter than
> having BC breaks only in majors? Is it not easier to make one or two smal=
l
> 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 i=
n
> 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 mo=
re
> 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.
>

It's more than just a matter of time and convenience, though.  It also has
to do with expectations.  There is a predominant expectation that upgrading
minor increments on the same major release branch is essentially safe; that
you won't have to worry about BC breaks-- minor or otherwise-- causing your
code to start failing.  Furthermore, as someone else already pointed out,
"major" and "minor" can be very subjective terms and would likely lead to
increased confusion.  Many maintainers would probably opt not to just stay
on their current version rather than risk a BC break that someone here
regarded as "minor" causing their code to blow-up.  This is especially
problematic given that essential security updates and bug fixes are
frequently included in minor version releases.  It could be argued that
staying current with the latest minor increment on whatever major branch
you're on is more important than being on the latest major increment for
that very reason.  I fear that this proposal would undermine that and erode
the trust people currently have in our minor releases to be BC-friendly,
drastically curtailing the proliferation of critical bug fixes and security
updates.

Historically, we haven't had much trouble on that side of the coin and I'd
prefer to keep it that way.  On the flip side, of course, there is also an
expectation that major increments will have BC breaks and will likely
require updates to your code; which, in turn, leads to the expectation that
adoption of new major version releases will be gradual.  I've often argued
here that we tend to allow known flaws to persist in major version
increments due to an inappropriate level of concern for BC in major release
increments and I still believe that.

That said, this proposal would represent the opposite extreme, making our
minor releases too unreliable in terms of BC for many people's comfort.
Also, the limit of 5 BC breaks seems completely arbitrary.  Why not 6?  Or
4?  There's no rational basis for that number that I can see and it could
potentially tie our hands when faced with a major revision of some kind
that would carry more BC breaks with it.


I do like the idea of having a clear, consistent policy regarding BC and
version increments.  I just don't think the specifics of the proposal are
the right way to go about doing that.

--Kris

--001a11c30504bc089905072bff8f--