> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
