Is the "No BC Breaks in Minor Releases" policy enforceable?

8 years ago by Nikita Popov — view source

unread

On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins 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 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:

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"

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]

8 years ago by Rowan Collins — view source

unread

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.

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]

8 years ago by Fleshgrinder — view source

unread

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.

Which would be arbitrarily laid out anyways. Think of the var keyword
deprecation RFC.

It was random, it is random, and it will be random I guess.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Nikita Popov — view source

unread

On Sun, Jun 12, 2016 at 8:21 PM, Rowan Collins rowan.collins@gmail.com
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]

8 years ago by Rowan Collins — view source

unread

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.)

OK, that at least is a specific line of reasoning. I don't agree with
it, but I can respect its logic.

For the record, I disagree because introducing an error changes program
flow, whereas introducing a warning does not (except if there is some
handler indiscriminately promoting warnings to errors, I guess, but I'm
not aware that that is common practice). Even with a "zero
notice/warning policy", it is possible to at least test your application
without fixing a new warning; with a new error, you have to fix the
problem before doing anything else. Or, more likely, you postpone
adoption of the new version, which is surely something we wanted to avoid.

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.

Unfortunately, this is still the case after this change: any parameter
which can currently be omitted will also accept nulls. The only way of
marking a parameter mandatory is to give it a type hint. So as the
author of a function, this change makes absolutely no difference to your
code; if you want a parameter to be mandatory, the solution in 7.1 as in
7.0 is to add a type hint. As the user of a function, it increases the
visibility of an existing warning; since you claim any "professional
codebase" will have a zero notice/warning policy anyway, this change
will make no difference there either.

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by Ferenc Kovacs — view source

unread

Hi,

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.

On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins 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.

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:

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"

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]

--

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

8 years ago by Davey Shafik — view source

unread

Apologies for top-post, am mobile.

I have discussed this with Joe briefly, and with a few others while at
PHPSC on Saturday.

My opinion:

I like and agree with the change despite voting no
I voted no ONLY due to the BC break and were I the sole RM and had I the
power I would chose to veto this change because of that.

It's one thing to break BC of undocumented weirdness such as the multiple
defaults in switches stuff. It's entirely another to change the behavior of
something that is documented in the language specification.

While code doing this is obviously wrong, if observed behavior is correct,
then the fact it is technically incorrect doesn't matter. Yes, this could
mean code is running with unintended side effects but there are two
outcomes for code currently hitting this warning:

the exception will be uncaught and fatal error instead of a warning
the exception will be caught by an unintended catch block - which could
potentially have unintended side effects, negating the only valid reason
for breaking BC.

Obviously Joe voted yes and disagrees with me on this.

¯_(ツ)_/¯

Davey

Hi,

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.

On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins 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.

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:

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"

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]

--

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

8 years ago by Anatol Belski — view source

unread

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?

Hi,

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.

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.

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:

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:

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"

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]

--
To unsubscribe,
visit: http://www.php.net/unsub.php

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

8 years ago by Joe Watkins — view source

unread

Morning internals,

As already explained, strictly following SemVer is not possible for a

project the size of PHP, with a release process such as PHP has.

Backward compatibility is important. Also important is the long term

goals for PHP, or at least for this major version of PHP: The goal is to
make Zend so efficient that generating machine code from user code becomes
a deployable solution.

I did request that the RFC were expanded with details about the

optimizations this "feature" makes impractical, I did get an extended
explanation in the discussion thread from Nikita, but the RFC was not
updated by Dmitry, as requested.

That's not to say that everything that makes an optimization possible

should get a green light, there will almost certainly be things I/we vote
no on because of BC concerns, but in this case, I see more value in the
break than I see in retaining the "feature".

I can be wrong, might be ... it doesn't really matter, the majority has

spoken. It is only my concern that the change is documented properly.

Cheers
Joe

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?

Hi,

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.

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.

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:

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:

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"

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]

--
To unsubscribe,
visit: http://www.php.net/unsub.php

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

8 years ago by Rowan Collins — view source

unread

Backward compatibility is important. Also important is the long term
goals for PHP, or at least for this major version of PHP: The goal is to
make Zend so efficient that generating machine code from user code
becomes a deployable solution.

OK, that's an interesting bit of background, which might explain why
Dmitry seemed in a hurry to get this in place. I was aware of the
discussion of performance, but not the background "long-term goal". Is
there a roadmap somewhere that describes this, or any background
discussion of doing this within the 7.x series, rather than planning for
8.0?

I can be wrong, might be ... it doesn't really matter, the majority
has spoken. It is only my concern that the change is documented properly.

This is my main concern, also. The RFC is very brief, and the discussion
period was artificially shortened, and I think the implications to the
BC policy make this RFC more important than Dmitry assumed.

Having a documented reason why a BC break was accepted in this case will
help to set expectations in the future. Ideally, this could lead to a
revised policy with BC guidelines that actually match the current
reality of the project, which the existing RFC does not seem to do.

Regards,

Rowan Collins
[IMSoP]

8 years ago by Joe Watkins — view source

unread

Afternoon internals,

Is there a roadmap somewhere that describes this, or any background
discussion of doing this within the 7.x series, rather than planning for
8.0?

We have no such sensible thing as a plan :)

The reason for the existence of PHP 7 (ng) is efficiency of the kind I
described, this is surely well understood by everyone.

What may not be well understood is that the job is nothing like complete.
Vigilant observers will have noticed that Dmitry does indeed have a JIT for
NG, which is very useful research, but it sucks so hard that we can't
deploy it.

The reason for this is that, in part, generated code doesn't look so much
different to code executed by the VM, though details differ considerably;
It needs to do at least the same job, it may need to do more (because of
guarding and other boring things).

Without knowing anything about generating instructions anyone can tell that
a complicated Zend, with all kinds of edge cases and inconsistencies
(specifically regarding ZE) is going to necessitate the generation of
complicated code, to accommodate those edge cases and inconsistencies.

A lot of effort is being put in to finding and resolving inconsistencies in
the engine such as this, a lot of effort has been expended and will be
expended on 7 in the pursuit of efficiency. A lot of this is of no
consequence to BC.

You can count the number of people putting in the majority of this effort
on your fingers ... erecting a road block in front of them in the name of
unobtainable BC is harmful to the apparent goals of the project at this
time.

The kinds of changes that must be delayed until 8.0 are surely going to be
proposed, and we will surely delay them by consensus.

This is my main concern, also

I will update the RFC, if Dmitry doesn't, when voting is closed.

I will ensure the change is properly documented in the manual also.

Ideally, this could lead to a revised policy

I think our policy has always been to consider each proposal on a
case-by-case basis. That's all I have done, and all I am suggesting others
do.

I know it's very strange to hear someone talking about "goals" ...

We can waste a bunch of time trying to define them, voting on them, and so
on ... or, we can look at what is going on, and what has gone on, and come
to sensible conclusions.

Cheers
Joe

On Mon, Jun 13, 2016 at 1:28 PM, Rowan Collins rowan.collins@gmail.com
wrote:

Backward compatibility is important. Also important is the long term
goals for PHP, or at least for this major version of PHP: The goal is to
make Zend so efficient that generating machine code from user code
becomes a deployable solution.
OK, that's an interesting bit of background, which might explain why
Dmitry seemed in a hurry to get this in place. I was aware of the
discussion of performance, but not the background "long-term goal". Is
there a roadmap somewhere that describes this, or any background discussion
of doing this within the 7.x series, rather than planning for 8.0?
I can be wrong, might be ... it doesn't really matter, the majority
has spoken. It is only my concern that the change is documented properly.

This is my main concern, also. The RFC is very brief, and the discussion
period was artificially shortened, and I think the implications to the BC
policy make this RFC more important than Dmitry assumed.

Having a documented reason why a BC break was accepted in this case will
help to set expectations in the future. Ideally, this could lead to a
revised policy with BC guidelines that actually match the current reality
of the project, which the existing RFC does not seem to do.

Regards,

Rowan Collins
[IMSoP]

8 years ago by Ferenc Kovacs — view source

unread

Afternoon internals,

Is there a roadmap somewhere that describes this, or any background
discussion of doing this within the 7.x series, rather than planning for
8.0?

We have no such sensible thing as a plan :)

The reason for the existence of PHP 7 (ng) is efficiency of the kind I
described, this is surely well understood by everyone.

What may not be well understood is that the job is nothing like complete.
Vigilant observers will have noticed that Dmitry does indeed have a JIT for
NG, which is very useful research, but it sucks so hard that we can't
deploy it.

The reason for this is that, in part, generated code doesn't look so much
different to code executed by the VM, though details differ considerably;
It needs to do at least the same job, it may need to do more (because of
guarding and other boring things).

Without knowing anything about generating instructions anyone can tell
that a complicated Zend, with all kinds of edge cases and inconsistencies
(specifically regarding ZE) is going to necessitate the generation of
complicated code, to accommodate those edge cases and inconsistencies.

A lot of effort is being put in to finding and resolving inconsistencies
in the engine such as this, a lot of effort has been expended and will be
expended on 7 in the pursuit of efficiency. A lot of this is of no
consequence to BC.

You can count the number of people putting in the majority of this effort
on your fingers ... erecting a road block in front of them in the name of
unobtainable BC is harmful to the apparent goals of the project at this
time.

The kinds of changes that must be delayed until 8.0 are surely going to be
proposed, and we will surely delay them by consensus.

This is my main concern, also

I will update the RFC, if Dmitry doesn't, when voting is closed.

I will ensure the change is properly documented in the manual also.

Ideally, this could lead to a revised policy

I think our policy has always been to consider each proposal on a
case-by-case basis. That's all I have done, and all I am suggesting others
do.

I know it's very strange to hear someone talking about "goals" ...

We can waste a bunch of time trying to define them, voting on them, and so
on ... or, we can look at what is going on, and what has gone on, and come
to sensible conclusions.

Cheers
Joe

On the other hand lack of release process and constant BC breaks also
hindered the adoption of past PHP versions.
With 7.0 we were in a good spot as we were able to package the BC breaks
with major performance improvements which makes it attractive for people to
upgrade(and still, with a successful 7.0 release we voted to delay the eol
date for 5.6).
While I don't want to impede progress we have to be careful about BC
breaks, and especially when from the outside it can be seen as some people
are above the rules/processes while others get gated by it.
From the user POV I really liked what we were doing in the past: mark stuff
first with E_DEPRECATED and then remove the feature later on.
I think that our main problem is that we don't have a roadmap for major
versions and historically our major release cycle was pretty slow (4.0.0:
2000, 5.0.0: 2004, 5.3 was basically a major version in 2009 and 7.0.0:
2015 dec), so now that a major just shipped people will try to squeeze in
BC breaks regardless of our release process (and yes, it doesn't not help
that the releaseprocess rfc was lacking clear definitions on some terms).
As I mentioned before I don't wanna impede progress so not trying to block
this specific rfc seeing how well the votes went, but I think it would be
useful for the future governance if we could:
1, update/expand our releaseprocess rfc so that it reflects the
actual/desired process and can spare us from the bureaucracy and word
twisting to suite one's current position.
2, figure out how can we do BC breaks in a more timely manner (either via
changing the releaseprocess, reclassifying what BC break means or having
more frequent major versions).

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

8 years ago by Fleshgrinder — view source

unread

You can count the number of people putting in the majority of this effort
on your fingers ... erecting a road block in front of them in the name of
unobtainable BC is harmful to the apparent goals of the project at this
time.

The work of these people is highly appreciated and actively as well as
publicly admired by the whole community. This is a fact.

That being said, this is not about erecting a road block in front of
them. This is about the same rights for all, something that is important
in a community, especially in a community without any kind of leadership.

Nobody is allowed to fix inconsistencies on an API level due to BC
concerns. Nobody is allowed to renamed some constants (T_PYJAMA_NEKO
anyone?) due to BC or nostalgic concerns.

Yes, that stuff is mainly cosmetically.

Yes, that stuff does not require the super magic skills that our engine
gurus possess.

Yes, you can count the people capable of doing any of this stuff on many
hands.

However, the rules should be the same for everyone in regards to BC. The
rules should be clear. The rules should be understandable. Randomness
and arbitrary decisions definitely do not help.

I currently also think of changes like the php_url struct that would fix
a bug but is an ABI break at the same time. This is being talked down in
the PR over at GitHub because of that break and the author was requested
to port it to PHP 7.1.

I also remember that there was once a PR with random numbers that was
meant to fix a bug but also stopped because of BC concerns (cannot find
it, cannot give a reference but Sara was involved).

What I am saying is. A BC promise cannot be arbitrary or it means BC
hell for users and frustration for people who would like to contribute
to internals. Simply because you one is not allowed to touch the code
unless you count to the few gurus who are allowed to do whatever they
want. (This is of course exaggerated now to make a point and biased.)

I think our policy has always been to consider each proposal on a
case-by-case basis. That's all I have done, and all I am suggesting others
do.

I know it's very strange to hear someone talking about "goals" ...

We can waste a bunch of time trying to define them, voting on them, and so
on ... or, we can look at what is going on, and what has gone on, and come
to sensible conclusions.

Ultimately meaning that there is no BC promise whatsoever and everyone
is at the mercy of the voters. This is especially striking me because
one of the main arguments against many RFCs that want to deprecate
something is that people will never upgrade because it makes upgrades
hard for them (note, we are talking about deprecations here and BCs in
much, much later versions). Introduction of random BCs is not?

We definitely should make up goals, clear goals. Goals that are
understandable by users. Goals that draw a vision of where we want to
go. Improving the performance and engine could be on top of that, I am
sure everybody will be in favor of it anyways. ;)

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Rowan Collins — view source

unread

Afternoon internals,

Is there a roadmap somewhere that describes this, or any background
discussion of doing this within the 7.x series, rather than planning for
8.0?

We have no such sensible thing as a plan :)

Heh, fair enough. :)

I think a roadmap for PHP in general would be no bad thing, actually -
somewhere to plot out longer term goals, and a way to make future
releases more visible. At the moment, it's quite unusual to that might
be less true if there were a draft list of features for 7.2, and indeed 8.0.

The reason for the existence of PHP 7 (ng) is efficiency of the kind I
described, this is surely well understood by everyone.

What may not be well understood is that the job is nothing like
complete. Vigilant observers will have noticed that Dmitry does indeed
have a JIT for NG, which is very useful research, but it sucks so hard
that we can't deploy it.
[...]
You can count the number of people putting in the majority of this
effort on your fingers ... erecting a road block in front of them in the
name of unobtainable BC is harmful to the apparent goals of the project
at this time.

This effort is absolutely appreciated, and I definitely don't want to
erect road blocks just for the sake of procedure.

That said, we do need to ensure we are on the same road, and that is
largely about communication. The last thing any of us wants is for
somebody to spend weeks working on an engine optimisation, then have it
conflict with what other people are trying to do at the language level.

This includes resisting the temptation to skip or fast-track processes,
and being clear in why a change is needed, and why it's needed now. The
more visibility there is of the big picture, the easier it becomes to
explain the details (e.g. "this change is necessary to progress the
project I was telling you about last month").

One idea that occurred to me was some form of regular update of what is
going on in engine development. Just a mail to the list a couple of
times a month saying "we have an interesting prototype of X; A is
working on a major refactoring of Y; B has managed to make Z 20% faster".

Ideally, this could lead to a revised policy

I think our policy has always been to consider each proposal on a
case-by-case basis. That's all I have done, and all I am suggesting
others do.

It may be the policy that people have been following, but it's not the
policy that's written down. A "revised policy" doesn't have to mean
changing what we do; it could mean describing what is currently
happening in a new RFC, so that our documentation matches reality.

Regards,

Rowan Collins
[IMSoP]

8 years ago by Dan Ackroyd — view source

unread

We have an RFC [too_few_args] about to pass that seems to break our
published Release Process.

The "Release Process" is an RFC: https://wiki.php.net/rfc/releaseprocess

There are no rules against a new RFC changing the decision from a previous RFC.

If you want to have rules that either limit what RFCs can be made, or
when certain RFCs can be introduced, then you almost certainly need to
introduce the concept of a 'constitution' or other set of rules that
exist above the RFC process.

If there is a BC break in an RFC, you are free to point this out as a
reason to vote against the RFC.

cheers
Dan
Ack

8 years ago by Rowan Collins — view source

unread

We have an RFC [too_few_args] about to pass that seems to break our
published Release Process.
The "Release Process" is an RFC: https://wiki.php.net/rfc/releaseprocess

There are no rules against a new RFC changing the decision from a previous RFC.

Sure, but if we are changing the decision of that RFC, we should at
least say so. Simply acting contrary to the agreed policy is not the
same as changing that policy.

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by Stanislav Malyshev — view source

unread

Hi!

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.

BC is inherently subjective and subject to judgement, since strictly
speaking any user-visible change, including bug fixes, can influence
outcome of some code, and thus break BC. And some unobviously visible
changes could too (e.g. making PHP engine 3 times faster could break
someone's security based on certain operation in PHP being slow).

Thus, we can state our promise to keep BC as much as we feel is
practical, but we should not make a suicide pact of "never change
anything, no matter the cost, no matter the circumstance". And the level
of acceptability raises from rightmost to leftmost digits, more to the
left, more BC break we can accept. But ultimately, I think, it is a case
by case basis, with some cases being obvious and some less obvious.

For this feature, given how useless and obscure non-passing required
parameters is and that it's almost always is a bug, I personally think
BC break it acceptable, though I admit it comes pretty close to the
line, but on my personal opinion, still does not cross it.

Finally, there's nothing "enforceable" in PHP as such - we do not have a
legal structure and there's no "force" one part of the community could
use on the other to "enforce" anything. It is unusual, different and
sometimes frustrating, but I think it worked surprisingly good so far.

--
Stas Malyshev
smalyshev@gmail.com

8 years ago by Dmitry Stogov — view source

unread

Hi,

Just take into account, that 7.0 was released more than after 10 years of php-5 life, and of course we don't have any plans or goal for 8.0 yet.

Waiting another 10 years for fixing inconsistencies, that we "missed" in 7.0, would limit our progress on bytecode and VM optimizations targeted to 7.1 and future progress in next minor versions.

Thanks. Dmitry.

8 years ago by Fleshgrinder — view source

unread

Hi,

Just take into account, that 7.0 was released more than after 10
years of php-5 life, and of course we don't have any plans or goal
for 8.0 yet.

Waiting another 10 years for fixing inconsistencies, that we "missed"
in 7.0, would limit our progress on bytecode and VM optimizations
targeted to 7.1 and future progress in next minor versions.

Isn't that just an excuse to creep in breaking changes? We all
understand the goal here and we all are in favor of it. The problem is
that it still is a breaking change. It would be better to elevate the
E_INFO to an E_WARNING and create that PHP-8.0 branch with the actual
error and start planning the 8.0 release.

PHP 5.4 was already like a PHP 6.0, it was simply not called that way.
Why not learn from past mistakes and improve upon them?

Having a release cycle that is faster than the current one would help
users and companies. People could plan according to it. People would
know what to expect and it would most certainly make it easier for all
of use to plan and align.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Dmitry Stogov — view source

unread

Hi,

Just take into account, that 7.0 was released more than after 10
years of php-5 life, and of course we don't have any plans or goal
for 8.0 yet.

Waiting another 10 years for fixing inconsistencies, that we "missed"
in 7.0, would limit our progress on bytecode and VM optimizations
targeted to 7.1 and future progress in next minor versions.

Isn't that just an excuse to creep in breaking changes? We all
understand the goal here and we all are in favor of it. The problem is
that it still is a breaking change. It would be better to elevate the
E_INFO to an E_WARNING and create that PHP-8.0 branch with the actual
error and start planning the 8.0 release.
In my opinion, the BC break is really minor (to be included into 7.1).
It may affect only buggy code, that can be fixed by removing unused
arguments.
This was repeated here for few times, and for now, the majority of
voters are agree.
I have nothing to add.

PHP 5.4 was already like a PHP 6.0, it was simply not called that way.
Why not learn from past mistakes and improve upon them?

Having a release cycle that is faster than the current one would help
users and companies. People could plan according to it. People would
know what to expect and it would most certainly make it easier for all
of use to plan and align.

Better planning might be great...
Anyone may propose an RFC to start 8.0 development with plan, goals,
estimations, release schedule, etc.

Thanks. Dmitry.

8 years ago by Stanislav Malyshev — view source

unread

Hi!

Isn't that just an excuse to creep in breaking changes? We all
understand the goal here and we all are in favor of it. The problem is
that it still is a breaking change. It would be better to elevate the
E_INFO to an E_WARNING and create that PHP-8.0 branch with the actual
error and start planning the 8.0 release.

Changing notice to warning is a breaking change too :) And I'm not sure
how rushing 8.0 helps anything if you're afraid of breaks - you get
useful features later but also bigger breaks. Long term it doesn't
matter anyway unless 7.1 is somehow special, which is not. Also, having
just two minor versions seems to be a little thin, unless there's a plan
to keep maintaining 7.x, in which case the question is - who's going to
do that?

--
Stas Malyshev
smalyshev@gmail.com

8 years ago by Fleshgrinder — view source

unread

Changing notice to warning is a breaking change too :) And I'm not sure
how rushing 8.0 helps anything if you're afraid of breaks - you get
useful features later but also bigger breaks. Long term it doesn't
matter anyway unless 7.1 is somehow special, which is not. Also, having
just two minor versions seems to be a little thin, unless there's a plan
to keep maintaining 7.x, in which case the question is - who's going to
do that?

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.

Quote from the initial message. There is no breakage by elevating an
E_NOTICE to an E_WARNING because the script continues to work without
anything. Yes, there might be a log entry from now on or (worse) a
custom error handler that is now going to jump in. As we all agreed
upon, not everything is avoidable and this particular RFC might even be
okay (I actually agree with all your reasoning but am still highly
afraid of the BC impact). It does not change the general topic being
discussed here.

Nobody said to release 8.0 right away but to start planning it. Also, if
there are enough changes pilled up to justify a new major than there is
nothing that speaks against only a few minor versions. The current
approach to release a major every 10 years is also weird. After all, PHP
did not mature as much as e.g. C or C++. Java 9 and 10 are also already
planned:

https://en.wikipedia.org/wiki/Java_version_history#Java_SE_9

Personally I think ignoring any BC promises is much more severe than
having another major pretty fast. The latter at least does not come as
little surprise box and clearly communicates what it is.

Many projects also have various release flavors to better cope with such
situations where developers feel blocked by the restrictions of BC.
Maybe that could be something for PHP too? Having a PHP 8.0.0-alpha.1 or
8.0.0-preview.1 that is released like our current minor releases. People
who feel adventurous may use it as is since it is stable but its API is
not and any upgrade may contain breaking changes.

The 7.x.x stable branch is continued being developed but all breaking
changes go into the 8.0.0-x.x mainline branch (an appropriate action is
taken in the 7.x.x stable branch like here with the raising from
E_NOTICE to E_WARNING).

Note that completely new features can directly go into both.

Nginx has a similar approach for instance, but so does Debian.

This "problem" is solvable and ignoring it or talking it down does not
help anyone! :)

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Rowan Collins — view source

unread

And I'm not sure
how rushing 8.0 helps anything if you're afraid of breaks - you get
useful features later but also bigger breaks. Long term it doesn't
matter anyway unless 7.1 is somehow special, which is not. Also, having
just two minor versions seems to be a little thin, unless there's a plan
to keep maintaining 7.x, in which case the question is - who's going to
do that?

In my mind, it's not a case of "rushing 8.0"; it's looking at what
features we want to release, and how to group and label them.

There seems to be an implication here that if we said we were labelling
a release 8.0, we'd be obliged to break things in it, rather than just
allowed to break them, which makes no sense to me. We're not going to
run out of version numbers by using them up too quickly.

I think this is where a road map would come in handy; nothing fancy,
just a list of things that are waiting to get into a release, and maybe
a general "theme" for each release. If there are lots of small but
breaking changes coming up, they could be grouped into a release, which
we would label 8.0. If we want those changes to get released quickly,
then that release would be soon.

The only difference over drip-feeding them into the 7.x series would be
that users would know when to expect things to break.

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by Pierre Joye — view source

unread

Hi,

Just take into account, that 7.0 was released more than after 10
years of php-5 life, and of course we don't have any plans or goal
for 8.0 yet.

Waiting another 10 years for fixing inconsistencies, that we "missed"
in 7.0, would limit our progress on bytecode and VM optimizations
targeted to 7.1 and future progress in next minor versions.

Isn't that just an excuse to creep in breaking changes? We all
understand the goal here and we all are in favor of it. The problem is
that it still is a breaking change. It would be better to elevate the
E_INFO to an E_WARNING and create that PHP-8.0 branch with the actual
error and start planning the 8.0 release.

PHP 5.4 was already like a PHP 6.0, it was simply not called that way.
Why not learn from past mistakes and improve upon them?

Having a release cycle that is faster than the current one would help
users and companies. People could plan according to it. People would
know what to expect and it would most certainly make it easier for all
of use to plan and align.

This is the plan. We did not manage to stick major releases in the
release process RFC as it was already very hard to get a compromise.

As I think it is a bit too early to plan 8.0, we should definitively
start to think about what we want/would like to focus. It can be like
7.0, no major breakages but on spot improvements that are not possible
in 7.x

About the BC breaks, the RFCs do not define them clearly. It is a
complex topic. Bugs fixes can be seen as BC breaks (old enough bugs
become features). However new warninngs (except fatal) are not
considered BC breaks. Behavioirs changes are and that's why some fixes
or improvements require a RFC. I understand that a RFC allowing to
break BC is not good thing from a policy point of view, but as far as
I can tell, the ones we chosen so far were more than welcome by the
communities, which is a good sign about our handling of BC breaks.

I also understand the needs to change, update, optimize or clean our
edge cases to open the path to JIT and the likes. However I would be
very careful about that, and Dmitry and the team are very careful. I
also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

8 years ago by Jordi Boggiano — view source

unread

I also understand the needs to change, update, optimize or clean our
edge cases to open the path to JIT and the likes. However I would be
very careful about that, and Dmitry and the team are very careful. I
also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

+1 to that, it would be much better to introduce BC (strong/er) warnings
in 7.1/7.2 and then if needed branch off 8.0 already so that JIT work
can happen there with the BC warnings (and related features) removed.
8.0 could then come a year or two after 7.1 depending on how the JIT
work progresses. This would keep the "BC promise" intact instead of
going back to cowboy php days.

We are finally seeing more rapid PHP version adoption and I think it
would be a shame to break the trust PHP gained in the last few years of
stable and predictable releases.

Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

8 years ago by Rowan Collins — view source

unread

I also understand the needs to change, update, optimize or clean our
edge cases to open the path to JIT and the likes. However I would be
very careful about that, and Dmitry and the team are very careful. I
also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

+1 to that, it would be much better to introduce BC (strong/er) warnings
in 7.1/7.2 and then if needed branch off 8.0 already so that JIT work
can happen there with the BC warnings (and related features) removed.
8.0 could then come a year or two after 7.1 depending on how the JIT
work progresses.

Dmitry, Stas, do you think something like this could work? Could we have
a "php.next" preview branch with lots of performance work going on,
especially if a lot of it is focused around opcache anyway?

You could still raise RFCs for expected breaking changes, to make sure
you have approval for a language change before investing time depending
on it, but set their target as 8.0.
Users would know what to expect from each release, and have plenty of
notice to make their code "php8-ready".
Even if we're not ready to turn on JIT, an accumulation of
improvements would give users a more visible incentive to handle any
compatibility problems.
Grander plans that don't happen to be ready at the same time can
always go into 9.0 instead.

This would keep the "BC promise" intact instead of
going back to cowboy php days.

This. A hundred times this. Please don't let's make it harder to go from
7.0 to 7.1 than it was from 5.6 to 7.0.

Regards,

Rowan Collins
[IMSoP]

8 years ago by Joe Watkins — view source

unread

Morning,

This would keep the "BC promise" intact instead of going back to
cowboy php days.

Please don't let's make it harder to go from 7.0 to 7.1 than it was
from 5.6 to 7.0.

Can we reduce hyperbole to nil, please.

Before work starts on PHP 8, we need to have something worth branching,
just as we needed for 7, and 6.

There is no sense in which the too_few_args vote was unfair, biased, or
anything comparable to "the old days" (it wasn't committed without public
consultation).

The majority have decided that the extremely minor BC break is worth
the tradeoff.

Cheers
Joe

On Wed, Jun 15, 2016 at 5:10 PM, Rowan Collins rowan.collins@gmail.com
wrote:

I also understand the needs to change, update, optimize or clean our
edge cases to open the path to JIT and the likes. However I would be
very careful about that, and Dmitry and the team are very careful. I
also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

+1 to that, it would be much better to introduce BC (strong/er) warnings
in 7.1/7.2 and then if needed branch off 8.0 already so that JIT work
can happen there with the BC warnings (and related features) removed.
8.0 could then come a year or two after 7.1 depending on how the JIT
work progresses.

Dmitry, Stas, do you think something like this could work? Could we have a
"php.next" preview branch with lots of performance work going on,
especially if a lot of it is focused around opcache anyway?

You could still raise RFCs for expected breaking changes, to make sure
you have approval for a language change before investing time depending on
it, but set their target as 8.0.

Users would know what to expect from each release, and have plenty of
notice to make their code "php8-ready".

Even if we're not ready to turn on JIT, an accumulation of improvements
would give users a more visible incentive to handle any compatibility
problems.

Grander plans that don't happen to be ready at the same time can always
go into 9.0 instead.

This would keep the "BC promise" intact instead of

going back to cowboy php days.

This. A hundred times this. Please don't let's make it harder to go from
7.0 to 7.1 than it was from 5.6 to 7.0.

Regards,

Rowan Collins
[IMSoP]

8 years ago by Pierre Joye — view source

unread

Morning,

This would keep the "BC promise" intact instead of going back to
cowboy php days.

Please don't let's make it harder to go from 7.0 to 7.1 than it was
from 5.6 to 7.0.

Can we reduce hyperbole to nil, please.

Before work starts on PHP 8, we need to have something worth branching,
just as we needed for 7, and 6.

There is no sense in which the too_few_args vote was unfair, biased, or
anything comparable to "the old days" (it wasn't committed without public
consultation).

The majority have decided that the extremely minor BC break is worth
the tradeoff.

We have cases where our view on a problem and its impact was wrong, totally
wrong.

The rfc process allows veto even if accepted. I am very worried about how
things were done here. See my reply to Dmitry's approval mail for the
reasons.

8 years ago by Rowan Collins — view source

unread

Hi Joe,

Please don't let's make it harder to go from 7.0 to 7.1 than it was
from 5.6 to 7.0.

Can we reduce hyperbole to nil, please.

Sorry, yes, that was a bit hyperbolic on my part. I do think there is
the risk of making 7.0 to 7.1 as awkward an upgrade as 5.3 to 5.4, though.

The main problem I've encountered in 5.4 is the removal of the
already-deprecated call-time pass-by-reference, because it is an
invasive change that can't be worked around: you can't even test what
other impact the upgrade had until you've fixed it.

And at least that one could be detected with static code analysis; I'm
not even sure how to know if a code base would be affected by too_few_args.

Before work starts on PHP 8, we need to have something worth
branching, just as we needed for 7, and 6.

Again, this idea of a minimum requirement for PHP 8. I still haven't
seen anyone explain exactly what this means. If we have a bunch of
breaking changes, and those breaking changes are justified, then we can
justify a major release.

The majority have decided that the extremely minor BC break is worth the tradeoff.

Absolutely, a majority of voters have indicated that, while a minority
indicated they would support it in an 8.0 release. There's no reason we
have to accept "good enough" if we can agree a plan that is even better.

One thing I haven't seen stated very clearly is why there is a rush to
get this feature into a live release right now, with 7.1 already in
alpha. Is the plan to release major performance changes in 7.1.x?
Wouldn't most of those have to wait for 7.2.x anyway?

Regards,

Rowan Collins
[IMSoP]

8 years ago by Fleshgrinder — view source

unread

We are finally seeing more rapid PHP version adoption and I think it
would be a shame to break the trust PHP gained in the last few years of
stable and predictable releases.

Well spoken Sir! :)

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Levi Morrison — view source

unread

I also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

I agree with sentiment. However I do not mind certain BC breaks being
made in 7.1. For 7.2 and beyond I think we should be significantly
more strict on BC breakages.

8 years ago by Rowan Collins — view source

unread

I also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

I agree with sentiment. However I do not mind certain BC breaks being
made in 7.1. For 7.2 and beyond I think we should be significantly
more strict on BC breakages.

Why? What's special about 7.1? If it was a case of finishing off changes
that "should have been part of 7.0", I can see some kind of logic, but
the ones we're actually discussing seem to be more about "preparing for
8.0".

Regards,

Rowan Collins
[IMSoP]

8 years ago by Fleshgrinder — view source

unread

I also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

I agree with sentiment. However I do not mind certain BC breaks being
made in 7.1. For 7.2 and beyond I think we should be significantly
more strict on BC breakages.

Why? What's special about 7.1? If it was a case of finishing off changes
that "should have been part of 7.0", I can see some kind of logic, but
the ones we're actually discussing seem to be more about "preparing for
8.0".

Regards,

I agree fully with Rowan. Squeezing in those features that did not make
it into 7.0 is plain wrong and only creates problems. Everyone is always
so concerned about breaking something if someone proposes some
deprecation but in such cases nobody cares.

This is a very bad attitude!

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Stanislav Malyshev — view source

unread

Hi!

it into 7.0 is plain wrong and only creates problems. Everyone is always
so concerned about breaking something if someone proposes some
deprecation but in such cases nobody cares.

Because it's not about how it's proposed, but is about what impact it
will have on users. If you try to deprecate feature that is widely used,
you'd get a lot of pushback. If you try to change something that nobody
is using and nobody should be using, you'd get little to no pushback.

--
Stas Malyshev
smalyshev@gmail.com

8 years ago by Fleshgrinder — view source

unread

Hi!

it into 7.0 is plain wrong and only creates problems. Everyone is always
so concerned about breaking something if someone proposes some
deprecation but in such cases nobody cares.

Because it's not about how it's proposed, but is about what impact it
will have on users. If you try to deprecate feature that is widely used,
you'd get a lot of pushback. If you try to change something that nobody
is using and nobody should be using, you'd get little to no pushback.

Hey! :)

That does not match your usual argumentation which goes along the lines
that people expect a stable language and that they will turn to other
languages that are more stable if the language is not stable. We are
making the language unstable. Deprecating things and offering better
alternatives with a clear upgrade path is not breaking things, it is
improving. We are improving something in this case but without prior
notice and break stuff. Stuff we simply don't know of and cannot judge
at all.

I am still in favor if this change, fully and completely, as it is the
right thing to do and it helps catching bugs. I am even in favor of
adding more errors like this for other stuff like optional arguments
before non-optional ones. However, we need to prepare our users for that
(like with deprecations), inform them up front, and use the version
numbers to communicate that things will be broken. Many people do not
bother reading a CHANGELOG, following internals, or caring at all about
the language development. Hence, the pushback always comes later but
then it is too late.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Levi Morrison — view source

unread

I also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

I agree with sentiment. However I do not mind certain BC breaks being
made in 7.1. For 7.2 and beyond I think we should be significantly
more strict on BC breakages.

Why? What's special about 7.1? If it was a case of finishing off changes
that "should have been part of 7.0", I can see some kind of logic, but the
ones we're actually discussing seem to be more about "preparing for 8.0".

I didn't necessarily mean the currently proposed; I mean more
generally. For instance Nullable Types and the associated
ReflectionType changes both have small BC breaks that I don't mind. In
the case of the former there is a long-standing bug that did have BC
break impact that was fixed. This passed 44 to 1. Stas was the no-vote
and he can clarify his stance but I do not believe he voted no because
of the BC break.

In the case of ReflectionType it's cleaning up an API that was only
introduced in 7.0 to be better integrated with nullable types before
too many people are relying on it.

I think both of these BC breaks are reasonable for a minor that is
immediately following a major.

8 years ago by Levi Morrison — view source

unread

I didn't necessarily mean the currently proposed; I mean more
generally. For instance Nullable Types and the associated
ReflectionType changes both have small BC breaks that I don't mind. In
the case of the former there is a long-standing bug that did have BC
break impact that was fixed. This passed 44 to 1. Stas was the no-vote
and he can clarify his stance but I do not believe he voted no because
of the BC break.

Correction; 44 to 2. The other vote was Bwoebi's and he would prefer
full union types.

8 years ago by Rowan Collins — view source

unread

Why? What's special about 7.1? If it was a case of finishing off changes
that "should have been part of 7.0", I can see some kind of logic, but the
ones we're actually discussing seem to be more about "preparing for 8.0".
I didn't necessarily mean the currently proposed; I mean more
generally. For instance Nullable Types and the associated
ReflectionType changes both have small BC breaks that I don't mind. In
the case of the former there is a long-standing bug that did have BC
break impact that was fixed.

Ah, fair enough, thanks for clarifying.

As noted before, the nullable types case included careful analysis of
small BC breaks that were a side-effect of a major new feature being
released as part of 7.1. I wouldn't personally draw a distinction in
between adding it in x.1 vs x.2 or x.3; either the BC hiccup is
acceptable, or the feature should be roadmapped to x+1.0.

But the ReflectionType case definitely feels like clean-up of 7.0, so
makes sense to me as an example.

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by bjorn.x.larsson@telia.com — view source

unread

Den 2016-06-16 kl. 18:30, skrev Rowan Collins:

I also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

I agree with sentiment. However I do not mind certain BC breaks being
made in 7.1. For 7.2 and beyond I think we should be significantly
more strict on BC breakages.

Why? What's special about 7.1? If it was a case of finishing off
changes that "should have been part of 7.0", I can see some kind of
logic, but the ones we're actually discussing seem to be more about
"preparing for 8.0".

Regards,

The statement above by Levi makes perfect sense in my eyes and
what makes the early minor releases special after a major release
is that the uptake of 7.x is not so large yet. So running a migration
project from PHP 5.x targeting PHP 7 could go for either 7.0 or 7.1.

Going for later minor releases finding minor BC breaks then requires
another migration project, albeit small.

Regards //Björn Larsson

8 years ago by Rowan Collins — view source

unread

Just take into account, that 7.0 was released more than after 10 years
of php-5 life, and of course we don't have any plans or goal for 8.0 yet.

Waiting another 10 years for fixing inconsistencies, that we "missed" in
7.0, would limit our progress on bytecode and VM optimizations targeted
to 7.1 and future progress in next minor versions.

I'm certainly not talking about waiting 10 years. If anything, I'm in
favour of making breaking changes sooner, as long as we label them
properly.

Firstly, the historical release cycle for PHP major versions is 4-5
years, not 10; 5.x was an anomaly, but if you treat 5.3 or 5.4 as
stand-in for 6.0 (which in many ways they were) the cycle is pretty
consistent. So an 8.0 in 2019 or 2020 would fit the historical trend
perfectly. Secondly, there's no reason we need to be tied to that
history; we could say that from now on, every 3 years will be a new
major, or even every other release (a "tick tock" cycle of innovate and
stabilise).

If we wanted to, we could even scrap the notion of "minor" and "major"
releases, and, since we have one release a year, call them 2016.0,
2017.0, etc. Assuming we don't want to do that, there's presumably some
distinction in people's minds of what a major release means, and I guess
I'm trying to find out what that is.

Another way to look at it is to say "given the set of changes we have
for this release, what version number should we give it?" It sounds like
in your mind, a release would have to be something more than that to be
"worthy" of the 8.0 label; some grand plan, etc. In that case, maybe the
BC rule isn't really relevant, because we're "in the PHP 7 era",
regardless of what changes we're releasing?

(Note: I've deliberately tried to keep this thread about the policy in
general; for my concerns about this change in particular, see the other
thread.)

Regards,

Rowan Collins
[IMSoP]