On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins <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 like to joke that
fixing a segfault might break someones code because they used this segfault
as a "fast shutdown procedure". That's slightly over the top, but you get
the point.
So in the end it comes down to case-by-case decisions, with increasingly
higher thresholds when moving to the right of the dot. There are many "BC
breaks" that are so minor we routinely enact them as part of bug fixes in
patch releases. There are BC breaks so large that we'd certainly decline
them even for a major version, where technically anything is allowed --
after all, we *are* all concerned about adoption. And then there's a lot of
middle group between the two -- in that middle group people will write an
RFC and the voters will decide whether or not a particular BC break is
acceptable for a particular version. 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.
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.
In those cases it may be more obvious why the minor BC break is acceptable
to gain the benefit of a larger feature. 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.
Regards,
Nikita
> Hi All,
>
> The RFC to Replace "Missing argument" warning with "Too few arguments"
> exception [too_few_args] looks certain to pass (it currently stands at 36:8
> in favour), and contains the following:
>
> Backward Incompatible Changes: "The BC break in intended."
>>
> > Proposed PHP Version(s): "PHP 7.1"
>
> This appears to be in direct contradiction with the Release Process RFC
> [releaseprocess] adopted in 2010, which states:
>
> "x.y.z to x.y+1.z ... Backward compatibility must be kept"
>>
>
> There are two interpretations of this:
>
> 1) The policy in [releaseprocess] is binding, and the vote on
> [too_few_args] is invalid. Either the results should be ignored, or
> silently taken as acceptance of the feature in 8.0, and implementation
> postponed. However, there is no provision in the RFC for enforcement, and
> the RMs are explicitly denied such a role:
>
> "The roles of the release managers are about being a facilitator ... But
>> they are not: Decide which features, extension or
>>
> SAPI get in a release or not"
>
> 2) There is some reason that [releaseprocess] can be ignored in this case.
> However, there is no mechanism I can see in [releaseprocess], nor any
> justification in [too_few_args] or on its associated mailing list threads.
>
>
> It is often argued that "No BC" is too broad, and thus unenforceable. It
> is probably impossible to give a water-tight definition of what is
> acceptable, but we can state some general principles.
>
> The Introduction to [releaseprocess] implies the following aim:
>
> - To ensure a smooth and predictable upgrade process between minor
> releases.
>
> From this, I would consider the general spirit of the BC rule to be:
>
> - Any reasonably written PHP application which runs successfully under PHP
> x.y.z should run successfully under PHP x.y+1.z without significant
> modification.
>
> For instance, a program which runs fine under 5.3 may need invasive
> changes to remove call-time pass-by-reference before it runs on 5.4;
> preventing this seems to be the intent of the rule.
>
>
> Here is where things begin to get subjective, but the following seem
> reasonable to me, and seem to match most decisions made up until now:
>
> - Notices, Warnings, etc, may change severity, but must not become Errors
> or Exceptions.
> - An Error may be removed, or downgraded to a Warning, etc, if there is
> good reason to do so, e.g. new behaviour gracefully handles a previously
> unhandled case. (Many of the cases below boil down to this.)
> - The defined behaviour of operators must not change.
> - New operators, or application of operators to new situations, may be
> added, where such application would previously have been a error.
> - New keywords, functions, and classes may be reserved in the global
> namespace, because PHP "owns" this namespace. However, this must be done
> with care, and following the naming guide.
> - New arguments or type cases may be added to built-in functions.
> - Old arguments must not be removed from built-in functions.
> - Functions must not be removed, except for the special case of moving a
> "bundled" extension to PECL, such that loading the PECL module restores
> full compatibility.
> - Accidental and undocumented behaviour ("bugs") may be changed if some
> effort is made to demonstrate that it is not widely relied on.
> - The above rules may be broken only with careful justification, e.g. to
> remove a major security issue.
>
> Note that [releaseprocess] already states that justification must be
> provided for BC breaks, even where it allows them:
>
> It is critical to understand the consequences of breaking BC, APIs or
>> ABIs (only internals related). It should not be done for
>>
> the sake of doing it.
> > RFCs explaining the reasoning behind a breakage and the consequences
> along with test cases and patch(es) should help.
>
>
> If the above set of rules were adopted as binding, the vote on
> [too_few_args] would be invalid, because:
>
> - it promotes a warning to an error
> - the behaviour it is changing is documented and long-standing
> - it does not justify itself as a necessary exception to the rules
>
> I would be very interested to hear from those of you who voted "Yes" on
> [too_few_args] as to how you would formulate the rules instead.
>
>
> References:
> [too_few_args] https://wiki.php.net/rfc/too_few_args
> [releaseprocess] https://wiki.php.net/rfc/releaseprocess
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
