Hello, Am 30.03.2015 um 12:04 schrieb Ferenc Kovacs: > I know that our official release process allows that, but there are some > reasonable arguments against doing that and this topic was brought up > multiple times related to specific fixes. > I have two open PRs like that: > https://github.com/php/php-src/pull/1204 > https://github.com/php/php-src/pull/969 > and of course there are a bunch of similar ones from other people, and > there are cases when somebody simply pushes a change like that, other times > somebody points out that it should require an RFC( > https://wiki.php.net/rfc/json_preserve_fractional_part for example), but > most of the times we simply don't know what to do, and eventually we just > let the PR/patch to rot and die. > I would like to know if we can come up with a rule which can have consensus > behind it, and maybe formalize it as an extension to our current > releaseprocess rfc.
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. 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. Besides, I think that the vast majority of PHP users out there is using distro versions, so it does not matter to them if a feature goes into 5.6.7 oder 7.1.0, they will get the feature when the distro upgrades. But for the distro package maintainers and the users it would be a lot easier if e.g. the debian version could just be the latest patch version and not a mix of several versions after their package freeze. So, please let the x.y.z versions contain only additional (security) fixes and stick to the RFC process, thanks. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
