Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77960
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.170 as permitted sender)
References: <32b8315ede38cd03ad4a7ab4497397e9@mail.gmail.com>
 <CABBJUpc0T5_bcq+r3DNGyFLhkSdFV-acHzi5nmKWRiW5_vJiYA@mail.gmail.com> <CAMUwpuSd7Ojhrn4yh53iWzukztqo=jnH9zRnCi1HXRtLRTWkBg@mail.gmail.com>
In-Reply-To: <CAMUwpuSd7Ojhrn4yh53iWzukztqo=jnH9zRnCi1HXRtLRTWkBg@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQJhOtFYbNxiWbIyui1Tg5SfejmcmgFbpkdLAYALC1+a9cWjAA==
Date: Tue, 14 Oct 2014 12:05:50 +0300
Message-ID: <af333ee84905e4391ff0bfdf2b30c5e2@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>, Xinchen Hui <laruence@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] RFC: PHP 7.0 timeline
From: zeev@zend.com (Zeev Suraski)

> 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.

> 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.

> 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.

> 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.

Zeev