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. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
