Re: implication of the new release process regarding of new versions (moved from "Proposal to deprecate create_function()")

From: Date: Fri, 18 Oct 2013 16:55:17 +0000
Subject: Re: implication of the new release process regarding of new versions (moved from "Proposal to deprecate create_function()")
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-69691@lists.php.net to get a copy of this message
On Fri, Oct 18, 2013 at 6:29 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > On Fri, Oct 18, 2013 at 6:03 PM, Rowan Collins <rowan.collins@gmail.com> > wrote: > > > On 18/10/2013 15:51, Ferenc Kovacs wrote: > > > >> shouldn't really happen if you strictly follow the "new" release > >> process > >> rfc was accepted: > >> https://wiki.php.net/rfc/**releaseprocess< > 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< > 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(). > >> > > > > Ah, I see. I guess it was the slew of changes in 5.3 and 5.4 which made > it > > seem like this wasn't the case, because they would collectively have been > > 6.0. > > > yeah, and don't forget that 5.3 was already released, and the 5.4 branch > was already created before the new release process rfc got voted and > accepted, so that was the main reason why those versions had more BC > incompatible changes. > > > > So the aim is that a script made to work on PHP 5.4 will now be > guaranteed > > to run on any version <6, although some required modules might have moved > > to PECL? > > > > yeah, the current rfc promises that, plus there are some case-by-case > exceptions, mostly for bugfixing, plus it seems that introducing new > reserved keywords/class/method/constant names is not a BC break(would be > hard to introduce new features without that). > I think the general interpretation of that passage is "Only minor BC breaks possible". I.e. BC breaks only in uncommonly used functionality (removal of logo functions) or changes with little "direct" impact (like deprecation, which usually is super-annoying for people, but can be turned off if you want). Nikita

« previous php.internals (#69691) next »