On Tue, Oct 14, 2014 at 11:05 AM, Zeev Suraski <z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
