RE: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
| From: | François Laupretre | Date: | Wed, 01 Apr 2015 11:23:01 +0000 |
| Subject: | RE: [PHP-DEV] What's our official stance on small self-contained additions in a micro version | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-85634@lists.php.net to get a copy of this message | ||
> De : Dennis Birkholz [mailto:dennis@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