Hi Anatol, On Wed, Jan 27, 2016 at 6:28 PM, Anatol Belski <anatol....@belski.net> wrote: > If you're willing to work on fixing BC breaches till next minor RC, it might > be the way to proceed. If on the next RC we see no signs of regression, so we > could take it into the next minor. Otherwise, if we see that there are still > doubts on stability, we could stop trying to bring those changes in a stable > branch but go for master. Yasuo, it's really up to your willingness to spend > time on stabilizing, maybe also checking the Horde tests where the issues was > initially discovered, and being aware of possible risk that it possibly > wouldn't make it into stable. Anyways for the upcoming final, releasing your > patches seems risky.
I'm sure unit test failures cannot be fixed. It's relying on old buggy behaviors. Since I cannot fix users' unit tests, I fully agree to revert offending patches. In return, we'll have buggy behaviors, but it shouldn't be fatal because users have been living with them for a long time. Unlike other internal functions, session module functions expose many internal data and logic to user space. Even if changes should not affect normal operations, changes may break users' tests as they are testing abnormal cases usually. For this reason, I'll not commit changes to released versions from now on, if it changes exposed data/logic. e.g. Save handler execution order, session data manipulation logic. Please let me know if I should revert them. If it is not burden for you, please revert them by yourself. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
