Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78745
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABRjmp-oqEVtX-igQWsr-JkFmitqxn4YsyJ=mnzyHCN9Kj7akA@mail.gmail.com>
References: <CABRjmp-oqEVtX-igQWsr-JkFmitqxn4YsyJ=mnzyHCN9Kj7akA@mail.gmail.com>
Date: Wed, 5 Nov 2014 21:34:19 +0100
Message-ID: <CAH-PCH62GAecxC00aHgzgskG8zk58z1LBE1uBv81xtj6hRiy5w@mail.gmail.com>
To: Florian Margaine <florian@margaine.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c231541994d005072281e6
Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c231541994d005072281e6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014.11.05. 21:21 ezt =C3=ADrta ("Florian Margaine" <florian@margaine.com>)=
:
>
> Hi list,
>
> I'd like to introduce thresholds of backwards compatibility breaks, i.e.
> maximum numbers of allowed BC breaks per version.
>
> Lester's mail from a couple days ago had me thinking about the BC breaks
> that occur now and then in all the RFCs or all the mails I see these days=
.
> Now, take what I say with a grain of salt, as I've only recently been
> involved in this mailing list, as well as in php-src development.
>
> Let me explain my reasoning.
>
> To allow the users of PHP to upgrade their versions, and enjoy the new
> features, as well as the security fixes, the least number of BC breaks
> should get in the new released versions. That is because a BC break can
> lead to many hours of a codebase adaptation, hours that many companies
> don't want to pay for if the benefits are minimal.
>
> However, to allow us to evolve the language, BC breaks are a necessary
evil.
>
> Another issue is the short timeline of security fixes for the versions.
PHP
> 5.4 will have a total lifetime of 3 years, a very short one for many
> people. I'm not advising to increase this timeline, just saying that it
> gets in the equation of my discussion.
>
> To mitigate the issue of BC breaks, I think introducing the concept of
> thresholds would greatly help the PHP adoption, and mostly upgrades of PH=
P
> versions. If people know that a limited amount of work is going to be
> needed when upgrading a PHP version, the upgrades should be done more
often.
>
> For example, the following thresholds could be used:
>
> - major BC break: major versions only. 5 major BC breaks allowed per majo=
r
> version.
> - minor BC break:
>   - minor versions: 5 minor BC breaks allowed.
>   - patch versions: 1 BC break allowed.
>
> Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good
> idea?
>
> Regards,
> --
> Florian Margaine

You did not specify what does minor/major BC breaks mean, and for
micro/patch you did not specify minor/major.
I guess you meant minor BC break for a micro version, otherwise make no
sense (you can't have major bc break in a micro version but you can add it
with the next micro).

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.

Just my 2 cents ofc.

--001a11c231541994d005072281e6--