On Thu, Jan 23, 2014 at 11:56 AM, Lester Caine <[email protected]> wrote:
> Pierre Joye wrote:
>
>> I think we can clear these questions during the vote phases, as options.
>>
>> If anyone has an idea how to keep the advantage brought by the
>> renaming (compile checks, clarity, code correctness) without actually
>> doing the renaming in extensions, please fire it:)
>>
>
> Is this still being put forward for a PHP5.x build? Surely this along with
> a tidy up on base modules that support it would be much better used as a
> base for a new PHP6 plan? Extensions that do not support it can also be
> left out and we have a clean demarcation.
>
I agree with Lester (for once ^^). I think this change is too large for PHP
5.6. While the releaseprocess RFC does not guarantee compatibility of our
internal APIs, it does say that source compatibility *should* be preserved
for minor versions. Until now we stuck with that rule: Every minor release
a few APIs are changed, but "few" usually means something like three or
four, not five hundred.
If this patch is included in PHP 5.6 I think it is very likely that many
extensions will not be updated or take a long while in updating. It's one
thing to add two or three new ifdefs to support a new PHP release and
something entirely else to change virtually all types in your code and
verify that it is still safe with the new sizes.
I remember how lack of proper APC support was seen as a major problem with
adoption of PHP 5.4 - now imagine how lack of support by nearly all
extensions would look like...
As such I think that PHP 6 is a better place for this patch. PHP 6 will
presumably also clean up / change many other internal APIs, so we can have
all the major internal (and external ^^) breakage in one release. At that
point it might also make sense for many people to support separate versions
of extensions for PHP 5 and 6 to avoid the ifdef-hell.
Nikita