> De : Dennis Birkholz [mailto:den...@birkholz.biz] > > in my opinion all feature changes should go in the next X.Y version and > should require an RFC. > The reason is that "small self-contained changes" that get pulled in > without a discussion on internals and an RFC can easily lead to bad > design decisions in the long run.
Correct. The "small self-contained changes" concept easily leads to the rules not being the same for everyone. > I am sorry for the contributor but my example is > https://github.com/php/php-src/pull/1145 > (DateTime::createFromImmutable() method) which was posted here on the > list, got three negative replies but was merged nevertheless. I will not > reproduce the arguments here but now the door for a clean solution > inside the DateTimeInterface seems closed forever. This example is clearly an RFC released as a PR to bypass the rules (discussion, vote, and feature freeze date). I don't understand why it was accepted and merged. Can someone give the rule that was followed in this case ? If it should have gone through an RFC, can we revert the change and send him back to the RFC process ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
