On 19 March 2015 at 17:14, François Laupretre <franc...@php.net> wrote:
> As you may have noticed if you had a look at the RFC or twitter, I have > decided to follow people's suggestion. > Please note that the switch from E_DEPRECATED to fatal error won't require > any new RFC/discussion/vote > as the fatal error is considered as approved. I just introduce an > E_DEPRECATED phase for 7.0. What. The. Fuck. You edited the RFC after the voting had closed? You are not allowed to edit an RFC after the voting has occurred. I don't think we have any rules in place to deal with this; I don't think anyone anticipated that anyone would actually try to do this. We obviously need an explicit rule for this, but that can wait until 7.0 is closer to shipping, and we can contemplate RFC rules at leisure. For now, please revert the changes your made to the RFC after it had been closed. And whoever has the power to remove karma, please take the power to edit RFCs away from Francois once that has been done. > Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal > error in 7.1 or 7.2. You are being dumb here as well. We try to avoid breaking code in point releases. This BC break can only be done at a major version. E_DEPRECATED is not a magic bullet - that makes all BC problems go away. The reason why we voted on it for 7.0 is that it is a major break, but one that is acceptable to be done at a major version. It would not be acceptable to change the behaviour in a minor version. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
