Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93922
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.43 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>,
 PHP Internals <internals@lists.php.net>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
Message-ID: <46d516c5-ff2d-412c-87b0-75e3f72e87d0@gmail.com>
Date: Sun, 12 Jun 2016 14:18:03 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
 enforceable?
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> - We have an RFC [too_few_args] about to pass that seems to break our
> published Release Process.
> - Is the vote invalid, or do we need to change the Process?
> - The opinions of those who voted "Yes" are particularly requested.

BC is inherently subjective and subject to judgement, since strictly
speaking any user-visible change, including bug fixes, can influence
outcome of some code, and thus break BC. And some unobviously visible
changes could too (e.g. making PHP engine 3 times faster could break
someone's security based on certain operation in PHP being slow).

Thus, we can state our promise to keep BC as much as we feel is
practical, but we should not make a suicide pact of "never change
anything, no matter the cost, no matter the circumstance". And the level
of acceptability raises from rightmost to leftmost digits, more to the
left, more BC break we can accept. But ultimately, I think, it is a case
by case basis, with some cases being obvious and some less obvious.

For this feature, given how useless and obscure non-passing required
parameters is and that it's almost always is a bug, I personally think
BC break it acceptable, though I admit it comes pretty close to the
line, but on my personal opinion, still does not cross it.

Finally, there's nothing "enforceable" in PHP as such - we do not have a
legal structure and there's no "force" one part of the community could
use on the other to "enforce" anything. It is unusual, different and
sometimes frustrating, but I think it worked surprisingly good so far.

-- 
Stas Malyshev
smalyshev@gmail.com