On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 16/06/2016 17:24, Levi Morrison wrote: >>> >>> I also have to say that to the very short timeline to finalize 7.0 >>> should not be paid by breaking BCs in 7.x. We can have a short >>> timeline for 8.0 as well. If we need more drastic BC breaks earlier >>> than expected. If JIT is a goal for 8.0, then let do the BC breaks in >>> 8.0 and prepare our users using 7.x. >> >> >> I agree with sentiment. However I do not mind certain BC breaks being >> made in 7.1. For 7.2 and beyond I think we should be significantly >> more strict on BC breakages. > > > Why? What's special about 7.1? If it was a case of finishing off changes > that "should have been part of 7.0", I can see some kind of logic, but the > ones we're actually discussing seem to be more about "preparing for 8.0".
I didn't necessarily mean the currently proposed; I mean more generally. For instance Nullable Types and the associated ReflectionType changes both have small BC breaks that I don't mind. In the case of the former there is a long-standing bug that did have BC break impact that was fixed. This passed 44 to 1. Stas was the no-vote and he can clarify his stance but I do not believe he voted no because of the BC break. In the case of ReflectionType it's cleaning up an API that was only introduced in 7.0 to be better integrated with nullable types before too many people are relying on it. I think both of these BC breaks are reasonable for a minor that is immediately following a major. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
