Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Is the "No BC Breaks in Minor Releases" policy enforceable? »

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

php.internals

Rowan Collins

10 years ago
tl;dr: - We have an RFC [too_few_args] about to pass that seems to break our published Release Process. - Is the vote invalid, or do we need to change the Process? - The opinions of those who voted "Yes" are particularly requested. Hi All, The RFC to Replace "Missing argument" warning with "Too few arguments" exception [too_few_args] looks certain to pass (it currently stands at 36:8 in favour), and contains the following:
> Backward Incompatible Changes: "The BC break in intended." > Proposed PHP Version(s): "PHP 7.1"
This appears to be in direct contradiction with the Release Process RFC [releaseprocess] adopted in 2010, which states:
> "x.y.z to x.y+1.z ... Backward compatibility must be kept"
There are two interpretations of this: 1) The policy in [releaseprocess] is binding, and the vote on [too_few_args] is invalid. Either the results should be ignored, or silently taken as acceptance of the feature in 8.0, and implementation postponed. However, there is no provision in the RFC for enforcement, and the RMs are explicitly denied such a role:
> "The roles of the release managers are about being a facilitator ... But they are not: Decide which features, extension or
SAPI get in a release or not" 2) There is some reason that [releaseprocess] can be ignored in this case. However, there is no mechanism I can see in [releaseprocess], nor any justification in [too_few_args] or on its associated mailing list threads. It is often argued that "No BC" is too broad, and thus unenforceable. It is probably impossible to give a water-tight definition of what is acceptable, but we can state some general principles. The Introduction to [releaseprocess] implies the following aim: - To ensure a smooth and predictable upgrade process between minor releases. From this, I would consider the general spirit of the BC rule to be: - Any reasonably written PHP application which runs successfully under PHP x.y.z should run successfully under PHP x.y+1.z without significant modification. For instance, a program which runs fine under 5.3 may need invasive changes to remove call-time pass-by-reference before it runs on 5.4; preventing this seems to be the intent of the rule. Here is where things begin to get subjective, but the following seem reasonable to me, and seem to match most decisions made up until now: - Notices, Warnings, etc, may change severity, but must not become Errors or Exceptions. - An Error may be removed, or downgraded to a Warning, etc, if there is good reason to do so, e.g. new behaviour gracefully handles a previously unhandled case. (Many of the cases below boil down to this.) - The defined behaviour of operators must not change. - New operators, or application of operators to new situations, may be added, where such application would previously have been a error. - New keywords, functions, and classes may be reserved in the global namespace, because PHP "owns" this namespace. However, this must be done with care, and following the naming guide. - New arguments or type cases may be added to built-in functions. - Old arguments must not be removed from built-in functions. - Functions must not be removed, except for the special case of moving a "bundled" extension to PECL, such that loading the PECL module restores full compatibility. - Accidental and undocumented behaviour ("bugs") may be changed if some effort is made to demonstrate that it is not widely relied on. - The above rules may be broken only with careful justification, e.g. to remove a major security issue. Note that [releaseprocess] already states that justification must be provided for BC breaks, even where it allows them:
> It is critical to understand the consequences of breaking BC, APIs or ABIs (only internals related). It should not be done for
the sake of doing it.
> RFCs explaining the reasoning behind a breakage and the consequences
along with test cases and patch(es) should help. If the above set of rules were adopted as binding, the vote on [too_few_args] would be invalid, because: - it promotes a warning to an error - the behaviour it is changing is documented and long-standing - it does not justify itself as a necessary exception to the rules I would be very interested to hear from those of you who voted "Yes" on [too_few_args] as to how you would formulate the rules instead. References: [too_few_args] https://wiki.php.net/rfc/too_few_args [releaseprocess] https://wiki.php.net/rfc/releaseprocess Regards,
-- Rowan Collins [IMSoP]

Nikita Popov

10 years ago
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

Rowan Collins

10 years ago
On 12/06/2016 18:20, Nikita Popov 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.
> 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]

Fleshgrinder

10 years ago
On 6/12/2016 8:21 PM, Rowan Collins wrote:
> 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

Nikita Popov

10 years ago
On Sun, Jun 12, 2016 at 8:21 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 12/06/2016 18:20, Nikita Popov 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

Rowan Collins

10 years ago
On 12/06/2016 20:55, Nikita Popov wrote:
> 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]

Ferenc Kovacs

10 years ago
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: > > 1) The policy in [releaseprocess] is binding, and the vote on > [too_few_args] is invalid. Either the results should be ignored, or > silently taken as acceptance of the feature in 8.0, and implementation > postponed. However, there is no provision in the RFC for enforcement, and > the RMs are explicitly denied such a role: > > "The roles of the release managers are about being a facilitator ... But >> they are not: Decide which features, extension or >> > SAPI get in a release or not" > > 2) There is some reason that [releaseprocess] can be ignored in this case. > However, there is no mechanism I can see in [releaseprocess], nor any > justification in [too_few_args] or on its associated mailing list threads. > > > It is often argued that "No BC" is too broad, and thus unenforceable. It > is probably impossible to give a water-tight definition of what is > acceptable, but we can state some general principles. > > The Introduction to [releaseprocess] implies the following aim: > > - To ensure a smooth and predictable upgrade process between minor > releases. > > From this, I would consider the general spirit of the BC rule to be: > > - Any reasonably written PHP application which runs successfully under PHP > x.y.z should run successfully under PHP x.y+1.z without significant > modification. > > For instance, a program which runs fine under 5.3 may need invasive > changes to remove call-time pass-by-reference before it runs on 5.4; > preventing this seems to be the intent of the rule. > > > Here is where things begin to get subjective, but the following seem > reasonable to me, and seem to match most decisions made up until now: > > - Notices, Warnings, etc, may change severity, but must not become Errors > or Exceptions. > - An Error may be removed, or downgraded to a Warning, etc, if there is > good reason to do so, e.g. new behaviour gracefully handles a previously > unhandled case. (Many of the cases below boil down to this.) > - The defined behaviour of operators must not change. > - New operators, or application of operators to new situations, may be > added, where such application would previously have been a error. > - New keywords, functions, and classes may be reserved in the global > namespace, because PHP "owns" this namespace. However, this must be done > with care, and following the naming guide. > - New arguments or type cases may be added to built-in functions. > - Old arguments must not be removed from built-in functions. > - Functions must not be removed, except for the special case of moving a > "bundled" extension to PECL, such that loading the PECL module restores > full compatibility. > - Accidental and undocumented behaviour ("bugs") may be changed if some > effort is made to demonstrate that it is not widely relied on. > - The above rules may be broken only with careful justification, e.g. to > remove a major security issue. > > Note that [releaseprocess] already states that justification must be > provided for BC breaks, even where it allows them: > > It is critical to understand the consequences of breaking BC, APIs or >> ABIs (only internals related). It should not be done for >> > the sake of doing it. > > RFCs explaining the reasoning behind a breakage and the consequences > along with test cases and patch(es) should help. > > > If the above set of rules were adopted as binding, the vote on > [too_few_args] would be invalid, because: > > - it promotes a warning to an error > - the behaviour it is changing is documented and long-standing > - it does not justify itself as a necessary exception to the rules > > I would be very interested to hear from those of you who voted "Yes" on > [too_few_args] as to how you would formulate the rules instead. > > > References: > [too_few_args] https://wiki.php.net/rfc/too_few_args > [releaseprocess] https://wiki.php.net/rfc/releaseprocess > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Davey

10 years ago
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: 1) the exception will be uncaught and fatal error instead of a warning 2) 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 On Sun, Jun 12, 2016 at 21:48 Ferenc Kovacs <tyra3l@gmail.com> wrote:

Anatoliy Belsky

10 years ago
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

Joe Watkins

10 years ago
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 On Mon, Jun 13, 2016 at 12:22 AM, Anatol Belski <ab@php.net> wrote:

Rowan Collins

10 years ago
On 13/06/2016 10:35, Joe Watkins 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]

Joe Watkins

10 years ago
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:

Ferenc Kovacs

10 years ago
On Mon, Jun 13, 2016 at 4:32 PM, Joe Watkins <pthreads@pthreads.org> wrote:
> 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

Fleshgrinder

10 years ago
On 6/13/2016 4:32 PM, Joe Watkins wrote:
> 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.) On 6/13/2016 4:32 PM, Joe Watkins wrote:
> 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

Rowan Collins

10 years ago
On 13/06/2016 15:32, Joe Watkins wrote:
> 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]

Dmitry Stogov

10 years ago
Hi, The "obvious optimization" mentioned in the RFC, assumes just removing a line of code. https://github.com/zendtech/php-src/blob/zend-jit/ext/opcache/Optimizer/zend_inference.c#L2900 This may prevent run-time checks for IS_UNDEF on each read of the corresponding argument variables. I've just checked the effect of the patch on https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit It makes 2% speedup on bench.php (3.5% less CPU instruction retired). Anyway, performance is not the main reason of fixing the existing WTF behavior. And we do vote, especially to make common decisions on questionable topics. Thanks. Dmitry. ________________________________ From: Joe Watkins <pthreads@pthreads.org> Sent: Monday, June 13, 2016 12:35:27 PM To: Anatol Belski Cc: Ferenc Kovacs; Rowan Collins; Joe Watkins; davey@php.net; PHP Internals Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable? 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 On Mon, Jun 13, 2016 at 12:22 AM, Anatol Belski <ab@php.net> wrote:

Dan Ackroyd

10 years ago
On 12 June 2016 at 17:42, Rowan Collins <rowan.collins@gmail.com> wrote:
> - 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

Rowan Collins

10 years ago
On 12/06/2016 22:04, Dan Ackroyd wrote:
> On 12 June 2016 at 17:42, Rowan Collins <rowan.collins@gmail.com> wrote: >> - 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]

Stas Malyshev

10 years ago
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

Dmitry Stogov

10 years ago
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. ________________________________ From: Rowan Collins <rowan.collins@gmail.com> Sent: Sunday, June 12, 2016 7:42:46 PM To: PHP Internals Subject: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable? tl;dr: - We have an RFC [too_few_args] about to pass that seems to break our published Release Process. - Is the vote invalid, or do we need to change the Process? - The opinions of those who voted "Yes" are particularly requested. Hi All, The RFC to Replace "Missing argument" warning with "Too few arguments" exception [too_few_args] looks certain to pass (it currently stands at 36:8 in favour), and contains the following:
> Backward Incompatible Changes: "The BC break in intended." > Proposed PHP Version(s): "PHP 7.1"
This appears to be in direct contradiction with the Release Process RFC [releaseprocess] adopted in 2010, which states:
> "x.y.z to x.y+1.z ... Backward compatibility must be kept"
There are two interpretations of this: 1) The policy in [releaseprocess] is binding, and the vote on [too_few_args] is invalid. Either the results should be ignored, or silently taken as acceptance of the feature in 8.0, and implementation postponed. However, there is no provision in the RFC for enforcement, and the RMs are explicitly denied such a role:
> "The roles of the release managers are about being a facilitator ... But they are not: Decide which features, extension or
SAPI get in a release or not" 2) There is some reason that [releaseprocess] can be ignored in this case. However, there is no mechanism I can see in [releaseprocess], nor any justification in [too_few_args] or on its associated mailing list threads. It is often argued that "No BC" is too broad, and thus unenforceable. It is probably impossible to give a water-tight definition of what is acceptable, but we can state some general principles. The Introduction to [releaseprocess] implies the following aim: - To ensure a smooth and predictable upgrade process between minor releases. From this, I would consider the general spirit of the BC rule to be: - Any reasonably written PHP application which runs successfully under PHP x.y.z should run successfully under PHP x.y+1.z without significant modification. For instance, a program which runs fine under 5.3 may need invasive changes to remove call-time pass-by-reference before it runs on 5.4; preventing this seems to be the intent of the rule. Here is where things begin to get subjective, but the following seem reasonable to me, and seem to match most decisions made up until now: - Notices, Warnings, etc, may change severity, but must not become Errors or Exceptions. - An Error may be removed, or downgraded to a Warning, etc, if there is good reason to do so, e.g. new behaviour gracefully handles a previously unhandled case. (Many of the cases below boil down to this.) - The defined behaviour of operators must not change. - New operators, or application of operators to new situations, may be added, where such application would previously have been a error. - New keywords, functions, and classes may be reserved in the global namespace, because PHP "owns" this namespace. However, this must be done with care, and following the naming guide. - New arguments or type cases may be added to built-in functions. - Old arguments must not be removed from built-in functions. - Functions must not be removed, except for the special case of moving a "bundled" extension to PECL, such that loading the PECL module restores full compatibility. - Accidental and undocumented behaviour ("bugs") may be changed if some effort is made to demonstrate that it is not widely relied on. - The above rules may be broken only with careful justification, e.g. to remove a major security issue. Note that [releaseprocess] already states that justification must be provided for BC breaks, even where it allows them:
> It is critical to understand the consequences of breaking BC, APIs or ABIs (only internals related). It should not be done for
the sake of doing it.
> RFCs explaining the reasoning behind a breakage and the consequences
along with test cases and patch(es) should help. If the above set of rules were adopted as binding, the vote on [too_few_args] would be invalid, because: - it promotes a warning to an error - the behaviour it is changing is documented and long-standing - it does not justify itself as a necessary exception to the rules I would be very interested to hear from those of you who voted "Yes" on [too_few_args] as to how you would formulate the rules instead. References: [too_few_args] https://wiki.php.net/rfc/too_few_args [releaseprocess] https://wiki.php.net/rfc/releaseprocess Regards,
-- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Fleshgrinder

10 years ago
On 6/14/2016 12:43 PM, Dmitry Stogov wrote:
> 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

Dmitry Stogov

10 years ago
On 06/14/2016 07:17 PM, Fleshgrinder wrote:
> On 6/14/2016 12:43 PM, Dmitry Stogov wrote: >> 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.

Stas Malyshev

10 years ago
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

Fleshgrinder

10 years ago
On 6/14/2016 9:43 PM, Stanislav Malyshev wrote:
> 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? >
On 6/12/2016 6:42 PM, Rowan Collins wrote:
> 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

Rowan Collins

10 years ago
On 14/06/2016 20:43, Stanislav Malyshev wrote:
> 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]

Pierre Joye

10 years ago
On Tue, Jun 14, 2016 at 11:17 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 6/14/2016 12:43 PM, Dmitry Stogov wrote: >> 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

Jordi Boggiano

10 years ago
On 15/06/2016 11:41, Pierre Joye 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. 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

Rowan Collins

10 years ago
On 15/06/2016 12:38, Jordi Boggiano wrote:
> On 15/06/2016 11:41, Pierre Joye 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]

Joe Watkins

10 years ago
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:

Pierre Joye

10 years ago
On Jun 16, 2016 11:41 AM, "Joe Watkins" <pthreads@pthreads.org> wrote:
> > 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.

Rowan Collins

10 years ago
Hi Joe, On 16/06/2016 05:40, Joe Watkins wrote:
> > 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]

Fleshgrinder

10 years ago
On 6/15/2016 1:38 PM, Jordi Boggiano wrote:
> 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

Levi Morrison

10 years ago
> 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.

Rowan Collins

10 years ago
On 16/06/2016 17:24, Levi Morrison wrote:
>> 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]

Fleshgrinder

10 years ago
On 6/16/2016 6:30 PM, Rowan Collins wrote:
> On 16/06/2016 17:24, Levi Morrison wrote: >>> 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

Stas Malyshev

10 years ago
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

Fleshgrinder

10 years ago
On 6/16/2016 9:13 PM, Stanislav Malyshev wrote:
> 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

Levi Morrison

10 years ago
On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 16/06/2016 17:24, Levi Morrison wrote: >>> >>> 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.

Levi Morrison

10 years ago
> 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.

Rowan Collins

10 years ago
On 16/06/2016 19:11, Levi Morrison wrote:
> On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins<rowan.collins@gmail.com> wrote: > >> > >> >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]

Björn Larsson

10 years ago
Den 2016-06-16 kl. 18:30, skrev Rowan Collins:
> On 16/06/2016 17:24, Levi Morrison wrote: >>> 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

Rowan Collins

10 years ago
On 14/06/2016 11:43, Dmitry Stogov wrote:
> 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]