On Mon, Jan 28, 2013 at 4:59 PM, Pierre Joye <pierre....@gmail.com> wrote: > hi, > > On Mon, Jan 28, 2013 at 4:56 PM, Gustavo Lopes <glo...@nebm.ist.utl.pt> wrote: >> On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye <pierre....@gmail.com> >> wrote: >> >>> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski <z...@zend.com> wrote: >>>>> >>>>> -----Original Message----- >>> >>> >>>> Can you explain why you think it's a major BC break? The RFC suggested >>>> that the BC break would be minimal and that the likelihood a lot of people >>>> used it is very low. If you think differently and share it it might put it >>>> in a different light. >>> >>> >>> Problem is that we do not allow BC break in 5.5, at all, minor or not. >>> Minor vs major BC is all relative, a minor BC for someone can create >>> large issues for someone else, that's why we do not allow BC, in >>> general. Killing some outdated "security" features however may fit >>> better, but I am really not sure this one is worse the risk. >>> >> >> Sorry, this objection simply is not timely. >> >> In order for this voting thing to work, votes have to have a strong degree >> of finality. It would have to take a pretty strong new fact to overcome that >> finality. Otherwise, people will not have incentives to look *early* at the >> RFCs and the discussions will never end. >> >> In any case, the interpretation of the release process RFC as to BC breaks >> has been rather lax. 5.4 introduced pretty disruptive BC breaks like >> eliminating call-time pass-by-ref and changing the default encoding for >> htmlentities/htmlspecialchars and new keywords. 5.5 will also introduce a >> few (look at UPGRADING). > > I did not see any but the one about ini options we wanted to kill since years. > > If we introduced BC breaks other than those, then we'd to review them > and see why they have been introduced. But one thing is clear: we do > not allow BC breaks between 5.x and 5.x+1.
ok, reading the list, there is nothing remotely comparable to what you propose. However that's a non issue for 5.5 as this RFC only introduces a strict warning. I would suggest to modify it to specify that the removal will happen in the next major version. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
