2015.03.19. 18:40 ezt írta ("Dan Ackroyd" <dan...@basereality.com>):
>
> 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
>
We have no reason to think that this wasn't just a honest mistake, so there
is no reason for any sactions.
Personally I agree, we either remove it in 7.0(without prior deprecation as
we voted no for 5.7) or deprecate it in 7.0 and remove in the next major
version.
Everything else is a PITA and against our release process rfc.
