On 15/06/2016 11:41, Pierre Joye wrote:
I also understand the needs to change, update, optimize or clean our edge cases to open the path to JIT and the likes. However I would be very careful about that, and Dmitry and the team are very careful. 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.
+1 to that, it would be much better to introduce BC (strong/er) warnings in 7.1/7.2 and then if needed branch off 8.0 already so that JIT work can happen there with the BC warnings (and related features) removed. 8.0 could then come a year or two after 7.1 depending on how the JIT work progresses. This would keep the "BC promise" intact instead of going back to cowboy php days.
We are finally seeing more rapid PHP version adoption and I think it would be a shame to break the trust PHP gained in the last few years of stable and predictable releases.
Cheers -- Jordi Boggiano @seldaek - http://seld.be -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
