Re: Re: PHP 5.6.0beta2 Released for Testing!
| From: | Ferenc Kovacs | Date: | Fri, 02 May 2014 19:30:14 +0000 |
| Subject: | Re: Re: PHP 5.6.0beta2 Released for Testing! | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-73865@lists.php.net to get a copy of this message | ||
On Fri, May 2, 2014 at 7:56 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Fri, May 2, 2014 at 7:17 PM, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote:
>
> > Ferenc Kovacs in php.internals (Fri, 2 May 2014 19:02:13 +0200):
> > >On Fri, May 2, 2014 at 6:48 PM, Bob Weinand <bobwei9@hotmail.com>
> wrote:
> > >> At the time when doing this change, I had fixed all the bundled
> > extensions.
> > >>
> > >> So, e.g. opcache shouldn't be a problem.
> > >
> > >my bad, on a closer look, I can see that in ext/opcache it is
> conditional:
> > >#if ZEND_EXTENSION_API_NO <= PHP_5_5_API_NO
> > > case IS_CONSTANT_ARRAY:
> > >#endif
> >
> > At least 14 extensions will have to adjust their code and differentiate
> > between pre and post 5.6.
> >
> > >> Actually, I made the commit beginning of April, I think that are
> nearly
> > >> three months time to fix the extensions. I doubt that isn't enough…
> > >
> > >maybe, I just wish this could have happened a bit earlier in the
> process,
> > >and if we could have communicated it better (instead of waiting for the
> > >first ext dev to complain).
> >
> > Even with excellent communication it is hard to reach every dev. Xcache
> > is one example of an extension with little connections to the PHP
> > community. I think it will take a consirable time before Xcache is fit
> > for 5.6. there may be many more extensions out there that suddenly will
> > break.
> >
> > This will be a real hindrance to the acceptance of 5.6.
> >
>
> I feel like this issue is being taken somewhat out of proportions.
>
> PHP does not provide binary or extension source compatibility between minor
> versions. The API stays mostly the same, but there are always a few
> breakages to extensions. For example PHP 5.6 (unnecessarily) changed the
> signature of the zend_is_true function - *that* a change that will require
> changes to many extensions (grumble, grumble :)
>
> The IS_CONSTANT_ARRAY change on the other hand is constrained to very few,
> low-level Zend extensions (like bytecode caches or debuggers), which
> operate directly on VM oplines. The breakages between versions are usually
> a lot larger in this area than in the other, "normal" parts of the API.
> People writing this kind of extension are aware of that and used to it.
> Expecting the opcache source for 5.5 to be compatible with the 5.6 executor
> would be pretty crazy.
>
> Nikita
>
To quote the releaseprocess rfc: "ABI and API can be broken (internals),
src compatibility should be kept if possible, while breakages are allowed",
and imo nobody said here that we can't change internal API, but we were
talking about whether or not it worth or is the API change mandatory for
the bugfix which introduced it.
About the zend_is_true change, I think that the problem is that people
don't really care about changes like that as long as it goes to master, and
we always (since from like 5.4) end up branching from master, with all the
changes in it.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu