On 12/06/2016 18:20, Nikita Popov wrote:
On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins
<rowan.coll...@gmail.com <mailto:rowan.coll...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
