Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93913
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)
To: PHP Internals <internals@lists.php.net>
Message-ID: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
Date: Sun, 12 Jun 2016 17:42:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Is the "No BC Breaks in Minor Releases" policy enforceable?
From: rowan.collins@gmail.com (Rowan Collins)

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.


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]