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

Pierre, 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 agree it should not happen from 5.x.y to 5.x.y+1. But it definitely does break code... Not all, but at least some... > > > 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. Well, for a very limited subset of features possible sure... > > 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. I chose it for that specific reason. The line is blurry if taken literally (which many do)... Anthony