Re: Proposal to deprecate create_function()

On Fri, Oct 18, 2013 at 4:38 PM, Rowan Collins <rowan.collins@gmail.com>wrote: > On 18/10/2013 15:16, Pierre Joye wrote: > >> On Fri, Oct 18, 2013 at 7:13 AM, Rowan Collins <rowan.collins@gmail.com> >> wrote: >> >>> The absolute earliest this would actually be removed would be in 5.7, >>> sometime in 2015. In fact, deprecating now but not expecting removal to >>> be >>> possible until 5.8 / 2016 seems reasonable to me. >>> >> I don't think we can ever remove it in 5.x. >> > > Is there a particular rule that separates the kind of BC breaks that are > possible between 5.x releases vs those which would require bumping the > major version? It is absolutely not the case that a program written for PHP > 5.0 can be guaranteed to run under PHP 5.5 without modification. > > I thought PHP version numbers couldn't really be considered semantic like > that, ever since PHP 6 was abandoned, and major language features from it > were dropped into PHP 5.3 and 5.4. The current release policy could > plausibly continue indefinitely, with a 5.13 in 2021; "never" is a long > time... > > shouldn't really happen if you strictly follow the "new" release process rfc was accepted: https://wiki.php.net/rfc/releaseprocess , unfortunatelly it seems that there are some cases, when this can happen (some bug fixes, but the biggest offender was dropping deprecated features for 5.4.0 which were already removed in the 6.0 branch), but if you check out http://hu1.php.net/manual/en/migration55.incompatible.php you can see that the actual intentional BC breaks was really small, the only non bugfix BC break was removing the php logo urls, which was never meant to be a public api, but to be used by phpinfo(). -- Ferenc Kovács @Tyr43l - http://tyrael.hu