Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93918
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <027a527e-0920-9e57-b2cc-60fcbfedb84e@gmail.com>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <CAF+90c9FazFL9Do6xFKQmYR58QTd7cKePpf1LK7z74N9VkRB2A@mail.gmail.com> <027a527e-0920-9e57-b2cc-60fcbfedb84e@gmail.com>
Date: Sun, 12 Jun 2016 21:55:11 +0200
Message-ID: <CAF+90c8EKWBWvt1LzbyEYuL4L2GFQ6VQDiHzwND28x6Eca0XHw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1142847e510b3205351a266f
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1142847e510b3205351a266f
Content-Type: text/plain; charset=UTF-8

On Sun, Jun 12, 2016 at 8:21 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> 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.
>

Yeah, that's basically how I think about it. The voters use their best
judgment to determine what degree of breakage is acceptable for a
particular version. Of course the RFC author should also use their
judgement to determine whether a proposal is worthwhile at all.


> 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.
>

In that it is similar to the RFC on introducing warnings for invalid
numeric strings in arithmetic operations. Sure, that one introduces only a
notice while this one throws an exception. Most people probably don't share
this opinion, but I think there's actually very little difference between
the two for a professional codebase, which (obviously ^^) has a zero
notice/warning policy. In either case it's something that must be fixed.
(This means that the breakage, if defined as "work required for a
deployable upgrade", is probably much much higher for the invalid
arithmetic RFC, even though the breakage as in "how badly is the code
broken if I do nothing" is smaller.)


> 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?
>

A couple of factors involved here:
a) As you say, if code is affected by this change, it's likely that the
particular code segment was buggy and this bug has now been driven out of
hiding. Note that this can happen not only in legacy code that
categorically suppresses all warnings (and doesn't actually care if the
code works or not), but also in reasonably modern code where a stray error
suppression ends up affecting more code than indented. I specifically
remember an instance of much head-scratching about code behaving
"impossibly" due to a combination of runaway error suppression and this
condition being only a warning.
b) I don't think this BC break will affect a significant amount of code
when migrating from PHP 7.0 to PHP 7.1. Code that is currently running on
PHP 7.0 is unlikely in such a bad state as to be (negatively) affected by
this. Code that is on older versions will have to be looking about for many
other breaks while upgrading anyway.
c) If you subscribe to defensive programming, the current behavior implies
that you should actually be adding an assert(isset($param)) for each
parameter to the start of your function, to ensure that your **required**
parameters are really passed. WTF? If I can't rely on required parameters
being required in this programming language, what can I rely on at all? I'm
willing to accept a small degree of BC breakage to get rid of such nonsense.
d) As the RFC mentions, the current behavior prevents certain
optimizations. As someone who works on these optimizations, I'm
unreasonably biased in favor of changes that benefit optimization :P I
don't think this is a factor for most other voters.

Regards,
Nikita

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]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1142847e510b3205351a266f--