# [VOTE] Deprecate and remove calls from incompatible context - Thread: https://externals.io/message/65046 - Original archive: https://news-web.php.net/php.internals/65046 - Started by Gustavo Lopes on 2013-01-20T19:17:05+00:00 - Messages: 42 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/65046.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #65046 — Gustavo Lopes — 2013-01-20T19:17:05+00:00 URL: https://externals.io/message/65046#65046 I've opened the vote for the "remove calls from incompatible context" RFC: https://wiki.php.net/rfc/incompat_ctx#vote -- Gustavo Lopes --- ## #65246 — Gustavo Lopes — 2013-01-28T13:28:23+00:00 URL: https://externals.io/message/65046#65246 · In reply to: #65046 On Sun, 20 Jan 2013 20:17:05 +0100, Gustavo Lopes wrote: > I've opened the vote for the "remove calls from incompatible context" > RFC: > > https://wiki.php.net/rfc/incompat_ctx#vote > The RFC has been accepted unanimously. I'll implement it shortly. The change is trivial for 5.5 (change `E_STRICT` to E_DEPRECATED); for master, it should be fairly straightforward as well. -- Gustavo Lopes --- ## #65248 — Alan Knowles — 2013-01-28T14:17:21+00:00 URL: https://externals.io/message/65046#65248 · In reply to: #65246 Holy crap, how did you sneak this through.. my apologies for deleting the = vote, but i could not work out how to revert it. But this is a core php feature, for anyone who does not use traits.... We use this quite a bit, it may not be for purists, but it has worked perfectly for years. This is getting a bit silly, change for change sake.... Regards Alan Gustavo Lopes wrote: >On Sun, 20 Jan 2013 20:17:05 +0100, Gustavo Lopes > >wrote: > > > […] > > > […] > >The RFC has been accepted unanimously. I'll implement it shortly. The >change is trivial for 5.5 (change `E_STRICT` to E_DEPRECATED); for >master, >it should be fairly straightforward as well. > >-- >Gustavo Lopes > >-- > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. --- ## #65249 — Gustavo Lopes — 2013-01-28T14:24:21+00:00 URL: https://externals.io/message/65046#65249 · In reply to: #65248 > my apologies for deleting the = vote, but i could not work out how to > revert it. No problem, the result is still available at https://wiki.php.net/rfc/incompat_ctx?rev=1359379541 I don't know want to know what you were trying to do, though... > But this is a core php feature, for anyone who does not use traits.... > We use this quite a bit, it may not be for purists, but it has worked > perfectly for years. This is getting a bit silly, change for change > sake.... I'm not discussing this again on the merits, but note that by the time this feature is removed, no PHP version without traits will be maintained anymore. -- Gustavo Lopes --- ## #65250 — Ferenc Kovacs — 2013-01-28T14:37:43+00:00 URL: https://externals.io/message/65046#65250 · In reply to: #65248 > > Holy crap, how did you sneak this through.. > what do you mean by sneak? it was proposed and announced in the usual channels. > > my apologies for deleting the = vote, but i could not work out how to > revert it. > no problem, I've restored it, restoring an older version is done via clicking the old version, clicking edit, and saving the page. > > But this is a core php feature, for anyone who does not use traits.... We > use this quite a bit, it may not be for purists, but it has worked > perfectly for years. This is getting a bit silly, change for change sake.... > I've found this to be a huge wtf when you bump into, and already reported by E_STRICT, so I was sold to the arguments made in the RFC. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65251 — Alan Knowles — 2013-01-28T14:49:26+00:00 URL: https://externals.io/message/65046#65251 · In reply to: #65249 I was trying to vote against, for what it's worth. It's a major bc break with no obvious value, and what appears to be 7 days given to vote when every one is busy discussing a new property syntax. Traits is cute, but this was a amazing feature of the PHP language, not obvious, but it's pretty similar to Javascript, not sure why it would be so confusing..... Sorry for being contrary, but i was a but shocked that this was.going to be removed Regards Alan Gustavo Lopes wrote: >On Mon, 28 Jan 2013 15:17:21 +0100, Alan Knowles >wrote: > > > […] > > > […] > >No problem, the result is still available at >https://wiki.php.net/rfc/incompat_ctx?rev=1359379541 > >I don't know want to know what you were trying to do, though... > > > […] >traits.... > > […] > > > […] > >I'm not discussing this again on the merits, but note that by the time > >this feature is removed, no PHP version without traits will be >maintained >anymore. > >-- >Gustavo Lopes > >-- > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. --- ## #65252 — Gustavo Lopes — 2013-01-28T15:01:45+00:00 URL: https://externals.io/message/65046#65252 · In reply to: #65251 > I was trying to vote against, for what it's worth. > > It's a major bc break with no obvious value, and what appears to be 7 > days given to vote when every one is busy discussing a new property > syntax. > > Traits is cute, but this was a amazing feature of the PHP language, not > obvious, but it's pretty similar to Javascript, not sure why it would be > so confusing..... > > Sorry for being contrary, but i was a but shocked that this was.going to > be removed > You had more than 6 months to voice your concerns. There was a discussion when the feature was proposed during summer. I'm sorry you did not notice it, but I can't be spamming the list every once in a while to maximize the number of people that are aware of what's going on. Concerns about voting periods not having an upper bound notwithstanding, there was nothing remotely irregular about the way the process was conducted. I therefore find your comments about "sneaking this in" rather odd. Blame yourself instead. Again, I'm not commenting on the merits. -- Gustavo Lopes --- ## #65253 — Ferenc Kovacs — 2013-01-28T15:03:29+00:00 URL: https://externals.io/message/65046#65253 · In reply to: #65251 > I was trying to vote against, for what it's worth. > trying to re-open the vote and voting after Gustavo announced that the voting was closed? that's sounds a little bit weird. > > It's a major bc break with no obvious value, and what appears to be 7 days > given to vote when every one is busy discussing a new property syntax. > personally I don't think it is a major BC break, AFAIR it is an undocumented feature, it is marked by E_STRICT, and for the next release this change will be only bumping from `E_STRICT` to `E_DEPRECATED` so anybody out there depending on this will be notified and has time to deal with the issue before the next release after 5.5. closing the votes after 7 days is fine, and I think it wasn't closed to rush the decision but it seemed that nobody was against it. > > Traits is cute, but this was a amazing feature of the PHP language, not > obvious, but it's pretty similar to Javascript, not sure why it would be so > confusing..... > because $this doesn't make sense in a static call, and assuming the caller methods scope isn't something what you would guess beforehand trying it out. it is unintuitive and you will be surprised that it works when you first encounter this. > > Sorry for being contrary, but i was a but shocked that this was.going to > be removed > I think that if you have concerns it is better to talk it over so if we missed something then it will brought forth. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65254 — Leigh — 2013-01-28T15:07:17+00:00 URL: https://externals.io/message/65046#65254 · In reply to: #65251 > I was trying to vote against, for what it's worth. > > It's a major bc break with no obvious value, and what appears to be 7 days > given to vote when every one is busy discussing a new property syntax. > See other thread by Zeev :) > I've opened the vote for the "remove calls from incompatible context" RFC: > > https://wiki.php.net/rfc/incompat_ctx#vote > Gustavo, it's probably a good idea in future to be a little more verbose about the content of an RFC. The original mail didn't really give much context with what was being proposed, so was easily skimmed over I guess. That said, it *was* announced through the correct channels, and if you see and RFC and don't know what it's about, all you have to do is click it and see. > But this is a core php feature, for anyone who does not use traits.... We > use this quite a bit, it may not be for purists, but it has worked > perfectly for years. This is getting a bit silly, change for change sake.... > > So your code has been generating errors since 2006 and you didn't think to fix it? `E_STRICT` is an error just like any other. Ok, probably shouldn't start a discussion about this, but it was my first thought. --- ## #65255 — Leigh — 2013-01-28T15:10:43+00:00 URL: https://externals.io/message/65046#65255 · In reply to: #65249 > https://wiki.php.net/rfc/incompat_ctx > > An RFC for deprecating and removing $this from incompatible context. > > Comments are welcome. > > Gustavo, my apologies, the ORIGINAL mail did say a little more about it. --- ## #65256 — Zeev Suraski — 2013-01-28T15:30:27+00:00 URL: https://externals.io/message/65046#65256 · In reply to: #65251 > -----Original Message----- > From: Alan Knowles [mailto:alan@roojs.com] > Sent: Monday, January 28, 2013 4:49 PM > To: Gustavo Lopes; PHP Internals; Alan Knowles > Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible > context > > I was trying to vote against, for what it's worth. > > It's a major bc break with no obvious value, and what appears to be 7 days > given to vote when every one is busy discussing a new property syntax. > > Traits is cute, but this was a amazing feature of the PHP language, not > obvious, > but it's pretty similar to Javascript, not sure why it would be so > confusing..... > > Sorry for being contrary, but i was a but shocked that this was.going to > be > removed Alan, Can you explain why you think it's a major BC break? The RFC suggested that the BC break would be minimal and that the likelihood a lot of people used it is very low. If you think differently and share it it might put it in a different light. Zeev --- ## #65257 — Lester Caine — 2013-01-28T15:32:48+00:00 URL: https://externals.io/message/65046#65257 · In reply to: #65250 Ferenc Kovacs wrote: > > […] > I've found this to be a huge wtf when you bump into, and already reported > by E_STRICT, so I was sold to the arguments made in the RFC. I think that this is the point here ... In order for legacy code to even work, `E_STRICT` has to be disabled, so one does not see any problem. That is the whole point of the switch? There is no requirement to test code with the switch on, the wtf comes when something that is 'protected' by `E_STRICT` is later removed! This was one of the major rework areas on my own code and I can TOTALLY understand people taking the ADVISED ROUTE of switching `E_STRICT` off as an alternative solution. NOW the question is, what is the point of `E_STRICT` if it can't be avoided anyway? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #65258 — Alan Knowles — 2013-01-28T15:36:15+00:00 URL: https://externals.io/message/65046#65258 · In reply to: #65252 Ok, just checked the mailing list (and sorry for top-posting) July 31st. RFC announced Jul 31st - 6 or 7 mails at least one very negative, a couple for it. August 1,3,5,6 - 5 or 6 emails getting a bit off-topic. Jan 21st - call to vote (single email - no-one replied on list)... - got 15 +1 votes Jan 28th - announced success.. I know it's not deliberate, but it looks like this change is just a BC disaster waiting to happen, anyone who has been using PHP for more that a few years, before traits, knows this is how to simulate multiple inheritance, it's basically textbook PHP for some of us old boys.. ;) It looks like the justification in the RFC is basically it's a WTF for beginners. Sorry, but this is pretty identical to javascript behavior (which does take some understanding, but is very powerful), so there is no WTF, or surprise, once you seen it done, and understand it.. If you where suggesting that calling a non-static method from global scope would cause some kind of E_DEPRECIATED, I'd agree, it's a good idea. but I'm not convinced that this proposal is particularly well thought through. Ok, that's all for tonight ;) Regards Alan > > > > […] > > You had more than 6 months to voice your concerns. There was a > discussion when the feature was proposed during summer. I'm sorry you > did not notice it, but I can't be spamming the list every once in a > while to maximize the number of people that are aware of what's going on. > > Concerns about voting periods not having an upper bound > notwithstanding, there was nothing remotely irregular about the way > the process was conducted. I therefore find your comments about > "sneaking this in" rather odd. Blame yourself instead. > > Again, I'm not commenting on the merits. --- ## #65259 — Pierre Joye — 2013-01-28T15:45:43+00:00 URL: https://externals.io/message/65046#65259 · In reply to: #65256 hi Zeev, > > […] > Can you explain why you think it's a major BC break? The RFC suggested that > the BC break would be minimal and that the likelihood a lot of people used > it is very low. If you think differently and share it it might put it in a > different light. Problem is that we do not allow BC break in 5.5, at all, minor or not. Minor vs major BC is all relative, a minor BC for someone can create large issues for someone else, that's why we do not allow BC, in general. Killing some outdated "security" features however may fit better, but I am really not sure this one is worse the risk. Cheers, -- Pierre @pierrejoye --- ## #65260 — Zeev Suraski — 2013-01-28T15:47:54+00:00 URL: https://externals.io/message/65046#65260 · In reply to: #65259 > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Monday, January 28, 2013 5:46 PM > To: Zeev Suraski > Cc: Alan Knowles; Gustavo Lopes; PHP Internals > Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible > context > > hi Zeev, > > > > […] > > > […] > > Problem is that we do not allow BC break in 5.5, at all, minor or not. > Minor vs major BC is all relative, a minor BC for someone can create large issues > for someone else, that's why we do not allow BC, in general. Killing some > outdated "security" features however may fit better, but I am really not sure > this one is worse the risk. What does it mean then? That implementing this RFC waits for 6.0 or that it was invalid in the first place? Zeev --- ## #65261 — Ferenc Kovacs — 2013-01-28T15:48:04+00:00 URL: https://externals.io/message/65046#65261 · In reply to: #65257 > Ferenc Kovacs wrote: > > > […] > > I think that this is the point here ... > In order for legacy code to even work, `E_STRICT` has to be disabled, so one > does not see any problem. Please Lester, could you stop pretending that `E_STRICT` errors will crash your application and kill all the kittens? There are a bunch of people (myself included) who tries to write `E_STRICT` free code so that our application is fast and bugfree? Yes, there are people who ignore `E_STRICT` and `E_DEPRECATED` and I agree that having a zillion of those in the PEAR packages is a wrong thing. But currently it is the way to remove a feature: deprecate it both in the code and the manual, advertise in the release announcement, and remove it in the next version, hence people who are interested in keeping up with the changes will know what do they need to check and change. > That is the whole point of the switch? There is no requirement to test > code with the switch on, the wtf comes when something that is 'protected' > by `E_STRICT` is later removed! `E_STRICT` was introduced in 5.0 `E_DEPRECATED` was introduced in 5.3, `E_STRICT` was used for things that we use `E_DEPRECATED` now, but `E_STRICT` can be used stuff other than deprecating features (like suggesting better alternatives: http://lxr.php.net/xref/PHP_5_5/ext/date/php_date.c#1493 ) > This was one of the major rework areas on my own code and I can TOTALLY > understand people taking the ADVISED ROUTE of switching `E_STRICT` off as an > alternative solution. What do you mean by ADVISED ROUTE? I don't think we officially advised anybody for ignoring errors/warnings/etc. Maybe you mean that somebody from the php project advised you to ignore the `E_STRICT` messages in a 3rd party library that you are using and not wanting to clean up yourself? > NOW the question is, what is the point of `E_STRICT` if it can't be avoided > anyway? http://php.net/manual/en/errorfunc.constants.php "Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code." -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65262 — Pierre Joye — 2013-01-28T15:49:09+00:00 URL: https://externals.io/message/65046#65262 · In reply to: #65260 > What does it mean then? That implementing this RFC waits for 6.0 or that > it was invalid in the first place? Both, if the plan is to get that into 5.x. -- Pierre @pierrejoye --- ## #65263 — Ferenc Kovacs — 2013-01-28T15:52:32+00:00 URL: https://externals.io/message/65046#65263 · In reply to: #65259 > hi Zeev, > > > > […] > > > […] > that > > […] > used > > […] > in a > > […] > > Problem is that we do not allow BC break in 5.5, at all, minor or not. > Minor vs major BC is all relative, a minor BC for someone can create > large issues for someone else, that's why we do not allow BC, in > general. Killing some outdated "security" features however may fit > better, but I am really not sure this one is worse the risk. > > Cheers, > -- > Pierre > > @pierrejoye > > -- > > > > did you read the RFC? we would only deprecate this feature in 5.5. and we already have such changes in 5.5 like https://wiki.php.net/rfc/remove_preg_replace_eval_modifier -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65264 — Pierre Joye — 2013-01-28T15:56:27+00:00 URL: https://externals.io/message/65046#65264 · In reply to: #65262 > > > > […] > > Both, if the plan is to get that into 5.x. Let me clarify, in my previous mail, I meant 5.6, not 5.5. The RFC is clear that 5.5 will only get a strict warning, which is perfectly fine. However removing it in 5.6 is not allowed. -- Pierre @pierrejoye --- ## #65265 — Gustavo Lopes — 2013-01-28T15:56:50+00:00 URL: https://externals.io/message/65046#65265 · In reply to: #65259 On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye wrote: > > > […] > > > […] > > Problem is that we do not allow BC break in 5.5, at all, minor or not. > Minor vs major BC is all relative, a minor BC for someone can create > large issues for someone else, that's why we do not allow BC, in > general. Killing some outdated "security" features however may fit > better, but I am really not sure this one is worse the risk. > Sorry, this objection simply is not timely. In order for this voting thing to work, votes have to have a strong degree of finality. It would have to take a pretty strong new fact to overcome that finality. Otherwise, people will not have incentives to look *early* at the RFCs and the discussions will never end. In any case, the interpretation of the release process RFC as to BC breaks has been rather lax. 5.4 introduced pretty disruptive BC breaks like eliminating call-time pass-by-ref and changing the default encoding for htmlentities/htmlspecialchars and new keywords. 5.5 will also introduce a few (look at UPGRADING). -- Gustavo Lopes --- ## #65266 — Pierre Joye — 2013-01-28T15:59:28+00:00 URL: https://externals.io/message/65046#65266 · In reply to: #65265 hi, > On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye > wrote: > > > […] > > Sorry, this objection simply is not timely. > > In order for this voting thing to work, votes have to have a strong degree > of finality. It would have to take a pretty strong new fact to overcome that > finality. Otherwise, people will not have incentives to look *early* at the > RFCs and the discussions will never end. > > In any case, the interpretation of the release process RFC as to BC breaks > has been rather lax. 5.4 introduced pretty disruptive BC breaks like > eliminating call-time pass-by-ref and changing the default encoding for > htmlentities/htmlspecialchars and new keywords. 5.5 will also introduce a > few (look at UPGRADING). I did not see any but the one about ini options we wanted to kill since years. If we introduced BC breaks other than those, then we'd to review them and see why they have been introduced. But one thing is clear: we do not allow BC breaks between 5.x and 5.x+1. -- Pierre @pierrejoye --- ## #65267 — Pierre Joye — 2013-01-28T16:02:36+00:00 URL: https://externals.io/message/65046#65267 · In reply to: #65266 > hi, > > > > […] > > I did not see any but the one about ini options we wanted to kill since years. > > If we introduced BC breaks other than those, then we'd to review them > and see why they have been introduced. But one thing is clear: we do > not allow BC breaks between 5.x and 5.x+1. ok, reading the list, there is nothing remotely comparable to what you propose. However that's a non issue for 5.5 as this RFC only introduces a strict warning. I would suggest to modify it to specify that the removal will happen in the next major version. -- Pierre @pierrejoye --- ## #65268 — Lester Caine — 2013-01-28T16:37:35+00:00 URL: https://externals.io/message/65046#65268 · In reply to: #65261 Ferenc Kovacs wrote: > > Please Lester, could you stop pretending that `E_STRICT` errors will crash your > application and kill all the kittens? > There are a bunch of people (myself included) who tries to write `E_STRICT` free > code so that our application is fast and bugfree? > Yes, there are people who ignore `E_STRICT` and `E_DEPRECATED` and I agree that > having a zillion of those in the PEAR packages is a wrong thing. > But currently it is the way to remove a feature: deprecate it both in the code > and the manual, advertise in the release announcement, and remove it in the next > version, hence people who are interested in keeping up with the changes will > know what do they need to check and change. I'm not going to go back and list the problems. `E_STRICT` errors DO cause problems running legacy code. I've had plenty of white screens until `E_STRICT` was switched back off in PHP5.4! Things that are just warnings in PHP5.3. Since this is optional, some people 'opt' to ignore the warnings, just as they ignore the `E_DEPRECATED` ones. The problem comes as in the case of $this in static functions where the optional fixes are used to allow the code to run. PHP5.2 code works in 5.3 if warnings are hidden, but there is no guarantee the same code will run in 5.4 and it may well now blow up in 5.5. So I repeat the question, what is the point of providing a switch which disables warning such as over the $this and then pulling the plug on it in a later version. This is the exact sort of activity that I have been moaning about all along. PHP5.3 and PHP5.4 introduced changes that should ideally have been reserved for a major update. PHP5 code should run without problems and complain in ANY later version of PHP5, not just some. That is what BC is all about! For a LONG time we could even write PHP4 code that ran in PHP5. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #65270 — Ferenc Kovacs — 2013-01-28T17:06:27+00:00 URL: https://externals.io/message/65046#65270 · In reply to: #65268 > Ferenc Kovacs wrote: > > > […] > > I'm not going to go back and list the problems. `E_STRICT` errors DO cause > problems running legacy code. I've had plenty of white screens until > `E_STRICT` was switched back off in PHP5.4! We told you that it shouldn't cause anything like that(except indirectly like taking up more memory or executing time and hitting a limit, or having a custom error handler which explicitly `exit()`s on an E_STRICT). We also told you to check your error log and if by any chance is a bug (what only you bumped into) then open a bugreport on http://bugs.php.net/preferably attaching a simple reproduce script, but you never did that as far as I can tell. So as far as we are concerned, `E_STRICT` works just fine. > Things that are just warnings in PHP5.3. the only thing that was changed in 5.4 related to `E_STRICT` was that `E_ALL` now includes E_STRICT, nothing else. 5.3 and 5.4 should behave in every other regard, if you think it isn't then please open a bugreport. > Since this is optional, some people 'opt' to ignore the warnings, just as > they ignore the `E_DEPRECATED` ones. yeah, those who don't wanna know or decide to ignore our runtime messages about features going away are free to do that. I can't see how and why should we change that, plus it would be a BC break. > The problem comes as in the case of $this in static functions where the > optional fixes are used to allow the code to run. PHP5.2 code works in 5.3 > if warnings are hidden, but there is no guarantee the same code will run in > 5.4 and it may well now blow up in 5.5. > the current releaseprocess RFC wouldn't allow that to happen in 5.x > > So I repeat the question, what is the point of providing a switch which > disables warning such as over the $this and then pulling the plug on it in > a later version. see above, we will (almost)always will deprecate a feature before removing it. taking away the option to silent those errors would be a pretty bad idea, and would be a major BC (to do that you would have to also change the current user error handler implementation, otherwise people would just ignore from there). removing a feature in a minor version is a different point, and it is indeed a BC break and it isn't allowed by the current releaseprocess RFC. personally I think that the current releaseprocess RFC will be either not followed all the times or we will release major versions more frequently, but time will tell. This is the exact sort of activity that I have been moaning about all > along. PHP5.3 and PHP5.4 introduced changes that should ideally have been > reserved for a major update. PHP5 code should run without problems and > complain in ANY later version of PHP5, not just some. That is what BC is > all about! For a LONG time we could even write PHP4 code that ran in PHP5. those versions were before us having formal RFCs, so features/changes was done and merged in a case-by-case basis. the major version bumps were always when the Zend Engine got rewritten, so only when the extension API was broken. the current releaseprocess in the other hand is a more stricter approach, it requires a major version bump for any userland BC break. so I think that you should be satisfied with the current situation as long as the releaseprocess is followed. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65280 — Pierre Joye — 2013-01-28T18:08:29+00:00 URL: https://externals.io/message/65046#65280 · In reply to: #65268 Lester, > I'm not going to go back and list the problems. `E_STRICT` errors DO cause > problems running legacy code. I've had plenty of white screens until > `E_STRICT` was switched back off in PHP5.4! Things that are just warnings in > PHP5.3. To be honest I am tired of your 1st level support questions and arguing. The white page syndrome is something that happens to any newcomer, say for the 1st half day of his work. Stop now to hi jack every discussion with totally pointless topics. You have questions about how to setup a production server to do not be impacted by notices? Ask on php-general or read the very well written documentation. -- Pierre @pierrejoye --- Next page: https://externals.io/message/65046.md?page=2