Re: What is our definition of a "Backward Compatibility Break"

hi, On Mon, Sep 10, 2012 at 8:23 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote: > Pierre, > > On Mon, Sep 10, 2012 at 1:54 PM, Pierre Joye <pierre.php@gmail.com> wrote: >> >> hi, >> >> On Mon, Sep 10, 2012 at 6:28 PM, jpauli <jpauli@php.net> wrote: >> > Based on our recent discussion on #pecl , I'd like we clarify what we >> > think is a "BCB" (Backward Compatibility Break) as well as what "only >> > minor BC breaks" could mean. >> >> Change in phpinfo related stuff are minor. Adding a notice or warning >> is minor or irrelevant. Changing return values (like suddenly >> returning array instead of integer, f.e.), behaviors or similar things >> are not allowed in x.y+1. > > > I'm not so sure about that. Adding a warning or notice may actually cause a > lot of headaches. See what happened with call-time-pass-by-reference in > 5.3... All of a sudden a lot of code that worked fine is flooding logs with > new warnings... it does not break code, also that happens only and only from 5.x to 5.x+1 and should not happen from 5.x.y to 5.x.y+1 for example (or on very rare cases). > I guess my point is that the line between a BCB and a minor BCB is a lot > finer and a lot more subjective that it seems on the surface. Is adding a > new language feature with a new keyword a BCB (since existing functionality > using that keyword is now a parse error), We add new features, that's no BC break as the feature did not exist before. Keyword is a problem, but we have to live with for now. > My take on it is this: > > If you can solve the "break" using nothing but static analysis and a static > conversion "script", then it's a minor break. So new keywords would be fine > (you could find/replace function yield() with function yield2() really > easily). But changing the semantics of code (returning an array instead of > an int, changing how references are passed, etc) would require developer > interaction to fix, and as such would not be minor. > > And one point on what classifies as a BC break: Everything. Any change will > break BC in some way. Even adding a function is a BC break since existing > code may use the same function names. Why we added namespace, no issue (well for 5.3+ :). > Fixing a segfault is a BC break as > well, as it's changing the way it works. That's really a totally wrong example. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org