Re: BC break in 5.4.29 and 5.5.13

On Tue, Jun 17, 2014 at 7:24 PM, Pierre Joye <pierre.php@gmail.com> wrote: > On Tue, Jun 17, 2014 at 3:49 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > > generally BC breaks are not allowed in micro versions, but this doesn't > > mean that we can't change existing behavior in micro versions. > > currently there are 3 cases where we have precedence changing behavior in > > micro versions: > > > > - bugfix > > - changing (explicitly) undefined behavior > > - introducing a new class/function/method/constant (I don't like this, > > but it seems that it is the consensus seems to be that this is okay).. > > It is definitively not OK. I cannot imagine any feature that cannot > x.y+1, which happens less than a year later. > > I agree with you, however the facts shows differently: http://php.net/ChangeLog-5.php#5.5.11 OPCache: Added function opcache_is_script_cached(). And even the releaseprocess rfc is written in a way, which implies that introducing new features are not considered as BC breaks: https://wiki.php.net/rfc/releaseprocess x.y.z to x.y+1.z Bugfixes *New features*Extensions support can be ended (moved to pecl) *Backward compatibility must be keptAPI compatibility must be kept (userland)* ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowed -- Ferenc Kovács @Tyr43l - http://tyrael.hu