the problem is to change existing tests to match a "possible fix", that defeats the whole purpose of testing possible BC breaks using our test suites.
We should definitively run x.y.0 tests during the whole x.y.0 life, and if something has to be changed, then it should be 1st be discussed, or RFC for big changes. And then it should indeed be documented as well, in the UPGRADING guide (should be done anyway for x.y+1 versions too). On Wed, Aug 24, 2011 at 12:24 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: > On Wed, Aug 24, 2011 at 12:00 PM, Pierre Joye <pierre....@gmail.com> wrote: >> agreed. >> > > about this specific change: > the real problem is that nobody spotted this change until we rolled > out the stable release, after that we can only chose from bad options. > we could have spotted this via two ways: > - those who participated in fixing > https://bugs.php.net/bug.php?id=53727 could have spotted this > - our tests should have start failing after the change > > AFAIK non of that happened, and fixing the first is hard, so I would > propose fixing the second (I know, it is already agreed and worked > toward) > > another problem is that the current(and before the change also) proto > was not forced by the function, so if is_a() would raise warnings when > non-object is passed to the first argument, this BC break would have > much less impact. > > so I got the idea that it would be usefull, if somebody could write a > script which fetches the proto for the functions/methods and does some > fuzzing which checks if the protos are enforced. > after that, we would have a list, and probably we could fix those > (changing the proto and the docs to the real behaviour, or vica > versa), and we could see whether the fix would impy BC and for those > cases we could just keep it as is for the stable branch and create > tests which would guarantee that changing the current behavior in the > stable branch wouldn't go unnoticed. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
