Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77964
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.41 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <af333ee84905e4391ff0bfdf2b30c5e2@mail.gmail.com>
References: <32b8315ede38cd03ad4a7ab4497397e9@mail.gmail.com>
 <CABBJUpc0T5_bcq+r3DNGyFLhkSdFV-acHzi5nmKWRiW5_vJiYA@mail.gmail.com>
 <CAMUwpuSd7Ojhrn4yh53iWzukztqo=jnH9zRnCi1HXRtLRTWkBg@mail.gmail.com> <af333ee84905e4391ff0bfdf2b30c5e2@mail.gmail.com>
Date: Tue, 14 Oct 2014 11:48:06 +0200
Message-ID: <CAMUwpuQdRTfxogKYaNP0adFV_7QOOsOHgaUD4PZDMSq1dnF2+w@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Xinchen Hui <laruence@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: PHP 7.0 timeline
From: jpauli@php.net (Julien Pauli)

On Tue, Oct 14, 2014 at 11:05 AM, Zeev Suraski <zeev@zend.com> wrote:
>> At the starting point (so, something like one year ago), we had many ideas
>> to
>> add to the new major PHP and had a compute of at least two years
>> development.
>
> Not every idea we have needs to go into 7.0.  Specifically, only ideas that
> require compatibility breakage have to go into 7.0, others can also go into
> 7.1 or later.

Makes sense, however, we should absolutely be sure to integrate every
BC idea we'd like to into 7.0
If not , one will have to wait something like 10 years if we don't
allow BC breaks in 7.X minors.

>
>> Also, we havent talked about a possible PHP 5.7, that could ease the
>> transition regading BC breaks brought by PHP7, issuing deprecation notices
>> for examples.
>
> We actually did several months ago.  I think the majority of people agreed
> that we should focus on 7.0, and only consider 5.7 if it became a necessity
> due to a prolonged 7.0 timeline, which I think we should do our best to
> avoid.
>
> I don't think we should be introducing any (significant) compatibility
> breakages into 7.0 that haven't already been deprecated as of 5.6.0.  Most
> users don't upgrade gradually and don't implement all minor versions anyway;
> Personally, I don't think an interim version that you need to upgrade to
> (5.7) and then upgrade yet again (7.0) will be very popular, to say the
> least.
>
>> Have we ported every extension ?
>
> Of course not.  It's up to extension maintainers to update their extensions.

Sure I was talking about Core exts.

>
>> Have we written some doc to extension
>> writters ?
>
> Yes.
>
>> Tools for them to ease migration ?
>
> Not sure what you mean by that but if you have ideas, you're welcome!
> Ultimately I think the only ingredient needed here is developer time, there
> aren't magic shortcuts - nor is this an ultra-complicated task anyway.

Ok, if something's been written (which seems to be the case), to
explain the big changes of internals, it is OK.
I could myself help on such parts, as when I'll start putting my head
into the new engine, I'll anyway review the whole source code, I could
at the same write docs.
Where is the actual migration doc you were talking about ?

>
>> Last, some big parts - ideas we had - have not been taken in
>> consideration,
>> nor debatted. Some are listed here :
>> https://wiki.php.net/ideas/php6/engine
>>
>> Quickly put : Asynchronous IO and network code rewriting - PHP/Zend
>> Extension code rewrite - Introduction of threads into the VM, refactor
>> TSRM
>> - SPL rewrite and merging .... and many other ideas.
>
> People who feel strongly enough about any of those ideas should turn them
> into RFCs and run them through for approval/rejection.  We can't wait on
> tentative lists of ideas forever.  The timeline I proposed provides ample
> time to do that, which again, balances the importance of releasing this
> major performance boosting update as early as possible, while taking
> advantage of the opportunities associated with a new major version.

It depends on the idea, some are absolutely huge rewrites, like AIOs,
Unicode or Threads.
Some are easier whith lower impact, like rewriting the extension
system (task I have ideas about and would write and RFC about)

Julien.P