On Wed, Apr 1, 2015 at 1:23 PM, François Laupretre <franc...@php.net> wrote:
> > 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. > this is what I feel, and one of the reasons for starting this thread. > > > 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 ? > > https://wiki.php.net/rfc/releaseprocess "No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis." "Bugfixes only (with a room for exceptions on a case by case basis and only for small self contained features additions)." The problem is that there is no definition/explanation for the case-by-case basis. Does it need a vote? Does it need prior discussion on the thread? Does it need explicit approval from the RMs? This problem was brought up in the past a couple of times (the releaseprocess RFC being too vague here and there also this specific issue about not having an agreed upon workflow for the approval process for micro versions), but no resolution was reached so there are examples where we have lengthly discussion and fullblown RFC for adding a new constant option to json_encode() while some other feature request just gets merged by an RM or maintainer of that given extension. I could accept any decision between holding off new features until next minor/major and allowing features explicitly without going through an RFC, but I want to have an explicit definition on what is allowed and how should the case-by-case process work. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
