On 15/06/2016 12:38, Jordi Boggiano wrote:
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.
Dmitry, Stas, do you think something like this could work? Could we have
a "php.next" preview branch with lots of performance work going on,
especially if a lot of it is focused around opcache anyway?
- You could still raise RFCs for expected breaking changes, to make sure
you have approval for a language change before investing time depending
on it, but set their target as 8.0.
- Users would know what to expect from each release, and have plenty of
notice to make their code "php8-ready".
- Even if we're not ready to turn on JIT, an accumulation of
improvements would give users a more visible incentive to handle any
compatibility problems.
- Grander plans that don't happen to be ready at the same time can
always go into 9.0 instead.
This would keep the "BC promise" intact instead of
going back to cowboy php days.
This. A hundred times this. Please don't let's make it harder to go from
7.0 to 7.1 than it was from 5.6 to 7.0.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
