On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski <z...@zend.com> wrote: > All, > > As we’re getting closer to release 5.6.0, and given the very high level of > interest in phpng, I think it’s time for us to provide some clarity > regarding what happens post 5.6.0. > > Dmitry and I wrote an RFC proposing that we merge phpng into master and > turn it into the basis of the next major version of PHP (name TBD). > > The RFC is available at https://wiki.php.net/rfc/phpng >
There are actually two questions here: 1. Do we want to base the next major version on phpng? 2. Do we want to merge phpng into master? The latter is tied to the question whether or not we want to have a PHP 5.7 release in the meantime. I'm not really sure whether or not that would be good, I would recommend opening a separate thread about that question. Regarding the first question, I fully support basing the next major on phpng. Several people in this thread have raised concerns regarding the quality of phpng's API. As someone who has ported a number of extensions to be compatible with phpng and is currently in the process of writing a >10kloc patch based on phpng, I can without any doubt say that the new APIs are a good bit more friendly to internals developers. Some of the reasons why that is so: * The removal of one level of zval indirection in many places, as well as the need to allocate zvals. * Changing the zend_hash APIs to directly return zvals/pointers and generally integrate better with zvals. * Changing the zend_hash APIs to handle lengths like everything else does. * The introduction of zend_string. >From my perspective phpng's APIs are an improvement over the current state, however there is still a lot of room for improvement. E.g. there is still a huge number of macros, which should probably be moved to inline functions, etc. I don't think anyone has a problem with doing these kinds of improvements, but I don't think they are really relevant to the question at hand (as these cleanups can happen regardless of which branch is used as the basis). I'd also love it if we could drop TSRMLS_* - iirc joe has a partial patch for better TLS handling, which couldn't be used previously due to concerns over internal API breaks. For a new majors those concerns shouldn't be a problem anymore :) Regarding the stability of the phpng branch: phpng definitely still contains bugs (which is quite obvious given the amount of code it changes) and I'm aware that it currently fails with many large testsuites. Obviously this will have to be resolved by the time we get anywhere close to a release. However we cannot wait until all bugs have been fixed before continuing other development for php next. We need a basis for php next and we need it now, so people know what they should develop against. This way stabilization of phpng will happen in parallel to other changes. Nikita
