Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93915
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <CAF+90c9FazFL9Do6xFKQmYR58QTd7cKePpf1LK7z74N9VkRB2A@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Message-ID: <027a527e-0920-9e57-b2cc-60fcbfedb84e@gmail.com>
Date: Sun, 12 Jun 2016 19:21:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c9FazFL9Do6xFKQmYR58QTd7cKePpf1LK7z74N9VkRB2A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
 enforceable?
From: rowan.collins@gmail.com (Rowan Collins)

On 12/06/2016 18:20, Nikita Popov wrote:
> On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins 
> <rowan.collins@gmail.com <mailto:rowan.collins@gmail.com>> wrote:
>
>     tl;dr:
>
>     - 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.
>
>
> There is an increasingly higher barrier for backwards compatibility 
> breaks going from a major version to a minor version to a patch 
> release. A strict policy of "no BC breaks" is completely and utterly 
> untenable, because even relatively simple fixes of obvious bugs have 
> some degree of BC impact and, with a user base as large as PHP has, 
> even changes that are "extremely unlikely" to affect anyone, probably 
> do affect someone.

I absolutely agree, and acknowledged this in my message.


> So in the end it comes down to case-by-case decisions, with 
> increasingly higher thresholds when moving to the right of the dot.

An elegant way of putting it. :)


> The whole idea of saying "the vote on the [too_few_args] RFC is 
> invalid because it violates the release process" sounds ludicrous to 
> me -- because the vote is there *precisely* to ascertain that this BC 
> break is considered acceptable for PHP 7.1, based on the cost-benefit 
> analysis of the individual voters.

My question, I guess, is what weight does the release process have in 
that decision? Or, to put it another way, who is it addressing? I guess 
you're saying that it is not the RFC author, but the individual voters, 
who are required to understand the policy, and enforce it against 
themselves, as it were.


> The only difference between the [too_few_args] RFC and a number of 
> other recent BC-breaking RFCs, including void types, nullable types 
> and invalid numeric string warnings, is that this RFC includes "only" 
> the BC break, while many other RFCs include a minor BC break as part 
> of a larger change.

No, the biggest difference is that all three of those RFCs extensively 
discusses the BC issues, and sets out a position as to why the break is 
acceptable in this case. too_few_args has a single sentence which 
amounts to a shrug of the shoulders.


> However in the end the same applies to too_few_args: It's a 
> cost-benefit tradeoff and as of now, the supermajority of voters have 
> made this tradeoff in favor of benefit.

A policy of "every BC break should be analysed as a cost-benefit 
tradeoff" might perhaps be a better one than we have now; it is not, 
however, what is written in the Release Process RFC.

To be clear, this RFC means that code which ran fine under 7.0 will 
produce fatal errors under 7.1, not because of conflict with a new 
feature, but because of a deliberate change whose only purpose is to 
produce those errors. As a user, that feels like breaking the promise 
expressed by the release process.


On a specific note, I would be interested to know why you think the 
change is justified. Is it because you think the affected code will be 
rare? Or because the code is "broken" anyway? Is there some guideline we 
can generalise, so that users, and future RFC authors, can know what is 
likely to be accepted in a minor release?


As a final thought, while looking through the archives, I notice that I 
have gradually moved from "concerned" to "strongly opposed", and I 
regret not considering the full impact sooner. I was perhaps carried 
along by Dmitry's confidence that this was a "mini RFC" which could be 
pushed through with minimal discussion (also technically a breach of 
policy: the voting RFC appears to require a 2-week discussion for the 
same RFCs that require a 2/3 majority).

Regards,

-- 
Rowan Collins
[IMSoP]