> by case basis. It is now very well known that when a fix requires a test > change, > then it often leads to bc breaks or similar issues. > > I do not think we have to argue about the semantics or general cases but how > to avoid such things and be sure that we break as less code as possible in > patches release.
In order to discuss how to avoid 'such things', we need to talk about different types of cases. > It is also obvious, as you stated, that there will have edge cases where we > have > to break existing codes, for security or critical reasons. This is > definitively not > the case here. It has nothing to do with security (criticality is subjective so I'm leaving it aside). The 3 bugs I mentioned (2 from 5.3.7 and one imaginary) have nothing to do with security, and yet we fixed them (or would have fixed them), despite the potential for people out there relying on the old behavior. It boils down to evaluating the severity of the bug and the likelihood that it'll break code. If it's a clear bug, which IMHO this is_a() issue was - then unless we're looking at code breakage at massive scale, it should be fixed. Again, I'm almost religious about retaining compatibility (even across major versions), but if we had a piece of code that was returning clearly the wrong value, we can't ignore it because some (my guess very few but who knows) relied on this behavior. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
