Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93926
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Sender: "Anatol Belski" <anatol.php@belski.net>
To: "'Ferenc Kovacs'" <tyra3l@gmail.com>,
	"'Rowan Collins'" <rowan.collins@gmail.com>,
	"'Joe Watkins'" <krakjoe@php.net>,
	"'Davey Shafik'" <davey@php.net>
Cc: "'PHP Internals'" <internals@lists.php.net>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com> <CAH-PCH5e6_aTCQEPd8=B0sFwsWsDfaG+2Fsp4i93t3qmxgmQQQ@mail.gmail.com>
In-Reply-To: <CAH-PCH5e6_aTCQEPd8=B0sFwsWsDfaG+2Fsp4i93t3qmxgmQQQ@mail.gmail.com>
Date: Mon, 13 Jun 2016 01:22:03 +0200
Message-ID: <020a01d1c501$3d3d9420$b7b8bc60$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHhFu+BeOi1jZIAuHFyxlmBguFiLgHpVQXcn7hpkpA=
Content-Language: en-us
Subject: RE: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?
From: ab@php.net ("Anatol Belski")

Hi,

> -----Original Message-----
> From: Ferenc Kovacs [mailto:tyra3l@gmail.com]
> Sent: Sunday, June 12, 2016 10:48 PM
> To: Rowan Collins <rowan.collins@gmail.com>; Anatoliy Belsky =
<ab@php.net>;
> Joe Watkins <krakjoe@php.net>; Davey Shafik <davey@php.net>
> Cc: PHP Internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
> enforceable?
>=20
> Hi,
>=20
> my interpretation is that no rfc with BC breaks should target a minor =
version.
> Our interpretation(based on past decisions and mailing list =
discussion) of BC
> break is changing any userland API except where we excplicitly stated =
that the
> previous behavior is undefined (and we also allow extensions to be =
moved to
> pecl, which from user POV can be a BC break but we allow that =
explicitly).
> I see a trend with php 7.1 that people try to add everything which we =
couldn't
> finish in 7.0 as it would be a complementary php 7.0 release, not a =
standard
> minor release which should abide our release
> process( https://wiki.php.net/rfc/releaseprocess ).
> Let me summon Anatol as he was the 7.0 release manager and Joe and =
Davey as
> they are the RMs for 7.1, let's see what do they think about this.
>=20
For 7.0 - it was a major version, so a bit more breaches were =
introduced. Many of such cases were conditioned by the internal changes =
so were unavoidable, but some were accepted intentionally. Still, my =
interpretation is close to yours, Ferenc, and the release process RFC is =
what I always refer to  when making a decision. But, even with 7.0, =
every case was evaluated individually.

For example, there was (and is) the case with throwing exceptions in =
core functions. While it would make sense for many cases, there was for =
one no general green light from the community. For two, there was (and =
are) several cases where a fatal error is unavoidable and an exception =
would be hard to implement. Still some new functionality was accepted =
with throwing exception in function by an explicit RFC after the feature =
freeze. Having that allowed in general were a paradigm change, so =
several PRs were rejected in that regard.=20

Thus, some cases can be quite controversial. As for me, the most what =
matters is - the API should be consistent, existing PHP scripts should =
still be functional, as much as possible. Even if something looks like =
making sense but would impede the adoption of a new version, it should =
be at least thought twice. I would call it a "generic recipe", still it =
won't be applicable for every single case. As striving to have =
everything BC free is not always possible and would block the actual =
language development or leave bugs open. While some cases can be solved =
by a simple discretion, others require a broad consent which is reached =
using the RFC instrument.

Regards

Anatol

> On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins =
<rowan.collins@gmail.com>
> wrote:
>=20
> > 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]
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > visit: http://www.php.net/unsub.php
> >
> >
>=20
>=20
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu