# RFC: PHP 7.0 timeline - Thread: https://externals.io/message/77951 - Original archive: https://news-web.php.net/php.internals/77951 - Started by Zeev Suraski on 2014-10-14T08:08:17+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/77951.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #77951 — Zeev Suraski — 2014-10-14T08:08:17+00:00 URL: https://externals.io/message/77951#77951 All, We’ve had some discussions about it during the version name & phpng RFC processes, and now that 5.6.0 is behind us – I think it’s time to get a more concrete game plan for PHP 7.0. I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe it strikes a good balance between early delivery to stay competitive, and having enough time to shape a major version. Given that we’ve already made some very substantial progress towards 7.0 (with phpng, AST, uniform variable syntax, etc.) – I think that timeline is very realistic, and perhaps we can even beat it. Restating the obvious, new features that don’t have compatibility implications can always be delivered in minor versions, i.e. 7.1, 7.2, etc. The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome! Zeev --- ## #77952 — Xinchen Hui — 2014-10-14T08:26:14+00:00 URL: https://externals.io/message/77951#77952 · In reply to: #77951 Hey: > All, > > > > We’ve had some discussions about it during the version name & phpng RFC > processes, and now that 5.6.0 is behind us – I think it’s time to get a > more concrete game plan for PHP 7.0. > > > > I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe > it strikes a good balance between early delivery to stay competitive, and > having enough time to shape a major version. Given that we’ve already made > some very substantial progress towards 7.0 (with phpng, AST, uniform > variable syntax, etc.) – I think that timeline is very realistic, and > perhaps we can even beat it. Restating the obvious, new features that > don’t have compatibility implications can always be delivered in minor > versions, i.e. 7.1, 7.2, etc. > > > > The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome! I think this process is a little long. we should freeze new features by the end of this year. then we could release 7 asap and regarding of the qa process, we can use 7.0.x to do that. thanks > > > > Zeev -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #77953 — Julien Pauli — 2014-10-14T08:46:15+00:00 URL: https://externals.io/message/77951#77953 · In reply to: #77952 > Hey: > > > > […] > > I think this process is a little long. > > we should freeze new features by the end of this year. then we could > release 7 asap > > and regarding of the qa process, we can use 7.0.x to do that. > > thanks Mmmm I don't think it is a good idea to rush the release. 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. 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. Also, what about breaks in ABI ? Have we ported every extension ? Have we written some doc to extension writters ? Tools for them to ease migration ? 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. Julien.Pauli --- ## #77955 — Xinchen Hui — 2014-10-14T08:51:25+00:00 URL: https://externals.io/message/77951#77955 · In reply to: #77953 > > > […] do you remember how PHP6 dies? thanks > > […] > > > Mmmm I don't think it is a good idea to rush the release. > > 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. > > 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. > > Also, what about breaks in ABI ? > Have we ported every extension ? Have we written some doc to extension > writters ? Tools for them to ease migration ? > > 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. > > > Julien.Pauli -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #77956 — Xinchen Hui — 2014-10-14T08:52:44+00:00 URL: https://externals.io/message/77951#77956 · In reply to: #77953 And: > > > […] we don't need to do all the ideas into PHP7. we will have 7.1, 7.2 eventually thanks > > […] > > > Mmmm I don't think it is a good idea to rush the release. > > 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. > > 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. > > Also, what about breaks in ABI ? > Have we ported every extension ? Have we written some doc to extension > writters ? Tools for them to ease migration ? > > 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. > > > Julien.Pauli -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #77957 — Stas Malyshev — 2014-10-14T09:00:30+00:00 URL: https://externals.io/message/77951#77957 · In reply to: #77955 Hi! > do you remember how PHP6 dies? I do. We failed to implement proper Unicode support. How is it relevant now? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #77958 — Pierre Joye — 2014-10-14T09:02:20+00:00 URL: https://externals.io/message/77951#77958 · In reply to: #77951 hi Zeev, > All, > > > > We’ve had some discussions about it during the version name & phpng RFC > processes, and now that 5.6.0 is behind us – I think it’s time to get a > more concrete game plan for PHP 7.0. > > > > I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe > it strikes a good balance between early delivery to stay competitive, and > having enough time to shape a major version. Given that we’ve already made > some very substantial progress towards 7.0 (with phpng, AST, uniform > variable syntax, etc.) – I think that timeline is very realistic, and > perhaps we can even beat it. Restating the obvious, new features that > don’t have compatibility implications can always be delivered in minor > versions, i.e. 7.1, 7.2, etc. > > > > The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome! Looks good to me. If we are done earlier, then good too. I will look into the details later. By the way, we were supposed to have one together to decide the 7 timeline and whether we wanted php 5.7, https://wiki.php.net/rfc/php7_57_roadmap. I was waiting you for weeks now after we discussed that with Andi. A little ping would have been nice. Anyway, I will remove the 7 section on the other RFC and go for it, if there are no other issue we cannot solve before voting, -- Pierre @pierrejoye | http://www.libgd.org --- ## #77960 — Zeev Suraski — 2014-10-14T09:05:50+00:00 URL: https://externals.io/message/77951#77960 · In reply to: #77953 > 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 --- ## #77961 — Stas Malyshev — 2014-10-14T09:07:24+00:00 URL: https://externals.io/message/77951#77961 · In reply to: #77952 Hi! > we should freeze new features by the end of this year. then we could > release 7 asap I think this is way too aggressive. This means basically next to nothing that is not already has prepared RC gets into 7, since only discussion + vote would take at least a month for anything substantial, and you have to also work on RFC and patch. And not everybody has time to work on all this fulltime, and some discussions can be slow or long-winded. I think Zeev's timeline looks much better in this regard. I think GA mid-October 2015 sounds a bit optimistic, but who knows, maybe it's me that it too pessimistic :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #77962 — Xinchen Hui — 2014-10-14T09:12:16+00:00 URL: https://externals.io/message/77951#77962 · In reply to: #77961 Hey: > Hi! > > > […] > > I think this is way too aggressive. This means basically next to nothing > that is not already has prepared RC gets into 7, since only discussion + > vote would take at least a month for anything substantial, and you have > to also work on RFC and patch. And not everybody has time to work on all > this fulltime, and some discussions can be slow or long-winded. > the problem here is, there is always new features if we wait... IMO, AST, INT64, NG, Uniforme variables style is enough for a new marjor version.. why we still need to wait? New features which missed PHP7.0, they can target at 7.1 instead. thanks > I think Zeev's timeline looks much better in this regard. I think GA > mid-October 2015 sounds a bit optimistic, but who knows, maybe it's me > that it too pessimistic :) > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #77963 — Dmitry Stogov — 2014-10-14T09:36:46+00:00 URL: https://externals.io/message/77951#77963 · In reply to: #77953 I think 1 year is reasonable timeline. We still have 5 month for active development and implementation of new ideas. I think https://wiki.php.net/ideas/php6/engine is a bit outdated. I'm not sure if anyone are going to work on proposals from 2009 (even if they are great). It would be great to define an ongoing set of changes that we would definitely like to see in PHP-7.0 including the responsible person(s) and time estimation. If something can't be developed by 7.0 release, it most probably may wait for 7.1. Thanks. Dmitry. > > > […] > believe > > […] > and > > […] > made > > […] > welcome! > > […] > > > Mmmm I don't think it is a good idea to rush the release. > > 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. > > 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. > > Also, what about breaks in ABI ? > Have we ported every extension ? Have we written some doc to extension > writters ? Tools for them to ease migration ? > > 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. > > > Julien.Pauli --- ## #77964 — Julien Pauli — 2014-10-14T09:48:06+00:00 URL: https://externals.io/message/77951#77964 · In reply to: #77960 > > […] > > 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. > > > […] > > 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. > > > […] > > Of course not. It's up to extension maintainers to update their extensions. Sure I was talking about Core exts. > > > […] > > Yes. > > > […] > > 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 ? > > > […] > > 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 --- ## #77965 — Jonny Stirling — 2014-10-14T10:06:13+00:00 URL: https://externals.io/message/77951#77965 · In reply to: #77964 Hi: > 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. > I have to agree with Zeev that we shouldn't wait for things that might or might not pop up, but keep track of any and act as appropriate if / when they do. I know that's not what you're getting at, just wanted to emphasize the point. Providing a formal list of what is being included / excluded from 7.0 in this regard may also be useful so there is no confusion later down the line. At the same time, which I think has been discussed before, perhaps it's time for a regular major release cycle (regular as in x (2-3?) years) so that there is a timescale for when new changes (or ones that might be intentionally or unintentionally missed / skipped for this major) that wouldn't be allowed in minor releases can be proposed / written against? Apologies for strictly being off-topic. Ta. Jonny. --- ## #77966 — Lester Caine — 2014-10-14T10:33:04+00:00 URL: https://externals.io/message/77951#77966 · In reply to: #77965 > At the same time, which I think has been discussed before, perhaps it's > time for a regular major release cycle (regular as in x (2-3?) years) so > that there is a timescale for when new changes (or ones that might be > intentionally or unintentionally missed / skipped for this major) that > wouldn't be allowed in minor releases can be proposed / written against? > > Apologies for strictly being off-topic. In hindsight I still feel PHP5.4 should have been a new major version which would have allowed a little more stability in the PHP5 stream, while allowing more flexibility to make changes. I was always fobbed of with 'It's only a number', but it IS a lot more than that. People are now referring to a 10 year period for the next major, but 5 year steps just seem a lot more manageable than 2 to 3 year steps? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #77971 — Rowan Collins — 2014-10-14T12:29:55+00:00 URL: https://externals.io/message/77951#77971 · In reply to: #77965 Jonny Stirling wrote (on 14/10/2014): > At the same time, which I think has been discussed before, perhaps > it's time for a regular major release cycle (regular as in x (2-3?) > years) so that there is a timescale for when new changes (or ones that > might be intentionally or unintentionally missed / skipped for this > major) that wouldn't be allowed in minor releases can be proposed / > written against? > > Apologies for strictly being off-topic. I actually think this is very much to the point. People keep saying "we can always do it in 7.1", but that implies that we could already have done it in 5.6 - i.e. it doesn't need a major version bump. What we should really be saying is "we can always do it in 8.0", but I suspect people are wary of saying that because it feels such a long way away. So, if we keep the timeline for 7.0 short, it would be nice to have at least tentative plan for how long before 8.0 - be it 3, 4, or 5 years. That would give some hope for the features that don't make it into 7.0 not being completely forgotten, and hopefully relieve the pressure to get it completely right this time. As has been pointed out before, a clear timeline for major releases would also allow much stricter enforcement of what is allowed in minor releases. 7.1 and 7.2 could be true minors, knowing that 8.0 was just around the corner with all the juicy bits in it. Regards, -- Rowan Collins [IMSoP] --- ## #77975 — Zeev Suraski — 2014-10-14T12:59:41+00:00 URL: https://externals.io/message/77951#77975 · In reply to: #77971 > -----Original Message----- > From: Rowan Collins [mailto:rowan.collins@gmail.com] > Sent: Tuesday, October 14, 2014 3:30 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] RFC: PHP 7.0 timeline > > Jonny Stirling wrote (on 14/10/2014): > > […] > > I actually think this is very much to the point. People keep saying "we > can > always do it in 7.1", but that implies that we could already have done it > in 5.6 > - i.e. it doesn't need a major version bump. That depends on the feature in question. The only features/changes that simply cannot make it into non-major releases are ones that break compatibility. Ideally there shouldn't be too many of those, regardless of our release timeline - to make the lives of our users easier. > What we should really be saying > is "we can always do it in 8.0", but I suspect people are wary of saying > that > because it feels such a long way away. We should try to push most of those into 7.0. We shouldn't release 7.0 with a long list of changes that we think should make it into 8.0. Instead, if we know about a change that requires a major version change - we should review it now, and decide for/against it. It's the non-compatibility-breaking-changes that we can safely say can wait for 7.1, because they can. > So, if we keep the timeline for 7.0 short, it would be nice to have at > least > tentative plan for how long before 8.0 - be it 3, 4, or 5 years. > That would give some hope for the features that don't make it into 7.0 not > being completely forgotten, and hopefully relieve the pressure to get it > completely right this time. > > As has been pointed out before, a clear timeline for major releases would > also allow much stricter enforcement of what is allowed in minor releases. > 7.1 and 7.2 could be true minors, knowing that 8.0 was just around the > corner with all the juicy bits in it. I think the 'juicy bits' comment suggests a possible misconception about what major versions are, at least in their current definition. We can push *any* type of juicy feature into a minor release, as long as it doesn't break compatibility. We've introduced plenty of new features in the 5.x family, including after we changed to the stricter rules on what can and cannot make it into a minor version. We needed 7.0 because phpng, AST and uniform variable syntax all break compatibility, although thankfully none of them does it in a very significant manner. Also, historically major versions also tended to bring performance improvements and substantial engine refactoring. But still, new features, including fairly major ones can make it into 7.x, exactly like they made it into 5.4/5.5/5.6. Zeev --- ## #77978 — Leigh — 2014-10-14T13:16:04+00:00 URL: https://externals.io/message/77951#77978 · In reply to: #77953 > > 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. > If we allow two years for development there will be too many changes to make adoption easy. I think it's smarter to split it into 2x one year developments (7.0 and 7.1), so that upgraders have a set of stable features after one year that they can begin migration work towards. --- ## #77982 — Jonny Stirling — 2014-10-14T13:21:47+00:00 URL: https://externals.io/message/77951#77982 · In reply to: #77975 > That depends on the feature in question. The only features/changes that > simply cannot make it into non-major releases are ones that break > compatibility. Ideally there shouldn't be too many of those, regardless of > our release timeline - to make the lives of our users easier. > > > […] > We should try to push most of those into 7.0. We shouldn't release 7.0 with > a long list of changes that we think should make it into 8.0. Instead, if > we know about a change that requires a major version change - we should > review it now, and decide for/against it. It's the > non-compatibility-breaking-changes that we can safely say can wait for 7.1, > because they can. > Hi Zeev, You are of course correct, a lot of changes can be made to minor versions and have been in the past that don't require a major. That doesn't change that there may be things missed (there may not, that's not the point), or ideas that come up after GA or even at the last minute e.g. in RCs or whatever that are wanted but have missed the 7 boat. Sure, get as much in as reasonably possible, but you potentially can't get everything that comes up and you definitely can't get anything that comes after release that requires a major. Some people may even be keeping stuff back as you've provided a currently expected set of changes. Nothing wrong with any of this, all is good. If there is a cycle in place and thus an expected timeline / process for *after* PHP7, then that surely makes the PHP7 timeline simpler to manage, it gives a milestone for new ideas to be worked against and more. If a good idea came through an RFC, but couldn't be done for PHP7, the RFC would be dropped as there is nothing currently beyond that. Tl;dr my thoughts are about after PHP7, which is itself looking pretty good. I just don't want for the community, or the awesome internals devs with great ideas walking away from things because there is no future plan. Again, apologies for the side-track. It's not really specific to the thread, but I still feel it's an important point. Ta. Jonny. --- ## #78037 — Stas Malyshev — 2014-10-14T17:14:57+00:00 URL: https://externals.io/message/77951#78037 · In reply to: #77962 Hi! > IMO, AST, INT64, NG, Uniforme variables style is enough for a new > marjor version.. why we still need to wait? We don't need to just "wait", as sit and do nothing. We need to allocate time for other features. > New features which missed PHP7.0, they can target at 7.1 instead. Only features that preserve BC, which is a limiting factor. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #78038 — Rasmus Lerdorf — 2014-10-14T17:24:47+00:00 URL: https://externals.io/message/77951#78038 · In reply to: #78037 > Hi! > > > […] > > We don't need to just "wait", as sit and do nothing. We need to allocate > time for other features. There are also quite a few really low-level changes in master right now. It is going to take quite a bit of time to stabilize. For example, something as basic as array iteration is inadvertently different: https://bugs.php.net/68215 PHP is a mature project with reams and reams of legacy code out there. Every single change, no matter how small, is like throwing a hand grenade in a lake. There is the initial explosion and chaos and then the ripples that go on and on. Dealing with all these ripples takes a lot more time than most people think. For people who think that 1 year from now is slow and conservative, it really isn't. It is quite aggressive given the number of really low-level changes that are already in master. Even if we froze the tree today I expect it could stretch to close to a year to stabilize. -Rasmus --- ## #78049 — Jonathan Wage — 2014-10-14T18:32:37+00:00 URL: https://externals.io/message/77951#78049 · In reply to: #77951 I like the 1 year timeline. It is an aggressive but achievable goal. > All, > > > > We’ve had some discussions about it during the version name & phpng RFC > processes, and now that 5.6.0 is behind us – I think it’s time to get a > more concrete game plan for PHP 7.0. > > > > I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe > it strikes a good balance between early delivery to stay competitive, and > having enough time to shape a major version. Given that we’ve already made > some very substantial progress towards 7.0 (with phpng, AST, uniform > variable syntax, etc.) – I think that timeline is very realistic, and > perhaps we can even beat it. Restating the obvious, new features that > don’t have compatibility implications can always be delivered in minor > versions, i.e. 7.1, 7.2, etc. > > > > The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome! > > > > Zeev > -- Connect with me on *http://twitter.com/jwage* > > […] > > There are also quite a few really low-level changes in master right now. > It is going to take quite a bit of time to stabilize. For example, > something as basic as array iteration is inadvertently different: > > https://bugs.php.net/68215 This is a known issue for which the test cases were marked as XFAIL because of the amount of work involved to get it fixed: https://github.com/php/php-src/commit/5831cca9576f4e0d4daed75a9915d436dfc5f4e5 > > PHP is a mature project with reams and reams of legacy code out there. > Every single change, no matter how small, is like throwing a hand > grenade in a lake. There is the initial explosion and chaos and then the > ripples that go on and on. Dealing with all these ripples takes a lot > more time than most people think. For people who think that 1 year from > now is slow and conservative, it really isn't. It is quite aggressive > given the number of really low-level changes that are already in master. > Even if we froze the tree today I expect it could stretch to close to a > year to stabilize. > > -Rasmus --- ## #78083 — Rasmus Lerdorf — 2014-10-15T00:39:04+00:00 URL: https://externals.io/message/77951#78083 · In reply to: #78082 > > > > > […] > > This is a known issue for which the test cases were marked as XFAIL because of the amount of work involved to get it fixed: > > https://github.com/php/php-src/commit/5831cca9576f4e0d4daed75a9915d436dfc5f4e5 Yes, I am aware of that. I was using it to illustrate the point that even with the changes currently in master, never mind any new things we might add, we have a lot of work left to do before we are anywhere near ready for a release. -Rasmus --- ## #78090 — Julien Pauli — 2014-10-15T08:13:06+00:00 URL: https://externals.io/message/77951#78090 · In reply to: #78083 > > > […] > > Yes, I am aware of that. I was using it to illustrate the point that > even with the changes currently in master, never mind any new things we > might add, we have a lot of work left to do before we are anywhere near > ready for a release. I agree, we must absolutely provide something stable, solid, performant and feature rich. This will take time to stabilize and spot edge cases, some of them could even lead to a reverse somewhere in the code. Julien.Pauli --- ## #78094 — Dmitry Stogov — 2014-10-15T10:39:12+00:00 URL: https://externals.io/message/77951#78094 · In reply to: #78038 If we aren't able to fix a low-level problem in a year we most probably won't be able to fix it in two as well. Also, the closer we are to release, the more feedback we get, and the more bugs are able to fix. Delaying release would just reduce the attention of the users. Thanks. Dmitry. > > > […] > > There are also quite a few really low-level changes in master right now. > It is going to take quite a bit of time to stabilize. For example, > something as basic as array iteration is inadvertently different: > > https://bugs.php.net/68215 > > PHP is a mature project with reams and reams of legacy code out there. > Every single change, no matter how small, is like throwing a hand > grenade in a lake. There is the initial explosion and chaos and then the > ripples that go on and on. Dealing with all these ripples takes a lot > more time than most people think. For people who think that 1 year from > now is slow and conservative, it really isn't. It is quite aggressive > given the number of really low-level changes that are already in master. > Even if we froze the tree today I expect it could stretch to close to a > year to stabilize. > > -Rasmus --- Next page: https://externals.io/message/77951.md?page=2