> Neither JIT nor FFI require backwards compatibility breaks in language. I > don't > think either of those particular features would substantially break the C API > either. If these are the motivations for PHP 8 then I strongly object.
Backwards compatibility breakages have never been the trigger for bumping into a major release. They were *allowed* in case a major release was made available - for different reasons. The trigger for a major release has always been very substantial improvements/changes to the language, which I believe JIT, FFI and potentially async squarely fit into (and I'll explain why I think that separately later this week). This is true for PHP 3, 4, 5 and 7 (even though 3 and 5 did introduce inherent compatibility breakages as a part of its new functionality). Just to provide an example, PHP 7 could have been close to 100.0% downwards compatible (not significantly more incompatible than other minor versions) - in fact when we worked on the phpng engine we went out of our ways to keep it downwards compatible. The way things flowed was that once we had this major-version-material in the form of a radically faster engine - we decided it was going to be a major version indeed, and this opened the door to introducing compatibility breaking changes as per our release policy. Not the other way around. Zeev
