# Let's make a 5.7 release - Thread: https://externals.io/message/76530 - Original archive: https://news-web.php.net/php.internals/76530 - Started by Andrea Faulds on 2014-08-15T00:48:19+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/76530.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 --- ## #76530 — Andrea Faulds — 2014-08-15T00:48:19+00:00 URL: https://externals.io/message/76530#76530 Good evening, I’ve kept putting this off, but given the current “move phpng to master” vote, I really can’t delay this any longer. It looks like PHP 7 is going to happen and phpng will be the base of that. While we could move straight to PHP 7 after the release of PHP 5.6, I think there is some merit in having one more 5.x release, namely 5.7, which would follow our usual release process and come out next year. PHP 7, as a major release, is likely to take much longer than a usual minor release. While some people might think one year is realistic, I highly doubt that, as I suspect phpng will not be the only new feature PHP 7 will contain. Major releases come with major changes, and I suspect some others will crop up, and these might delay the release. Because it will probably take two to three years, having a minor release in the meantime means userland developers won’t be starved of new features which don’t need to be in a major release and could be in a minor. Another point is that PHP 7 is probably going to break backwards-compatibility more significantly than minors would. For starters, phpng will break extension compatibility, and new proposals are likely to break userland compatibility as well. By making 5.7 happen, developers will have more time to switch to PHP 7 and can keep their existing codebases for longer. As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add deprecation warnings and such to help people prepare for 7. Finally, it is a fallback. If we do end up targeting 7 to come out next year, then if serious issues cause delays to 7, we will have a less ambitious and working new release to fall back on. I should clarify that I don’t wish to delay phpng at all, I am very much in favour of it and excited about it, nor do I expect this to delay it. We can simply work on two releases at once: PHP 7, an ambitious BC-breaking release to come out later, and PHP 5.7, a safe, non-breaking release that will come out next year with the usual schedule. Thoughts? Thanks! -- Andrea Faulds http://ajf.me/ --- ## #76531 — Levi Morrison — 2014-08-15T01:06:16+00:00 URL: https://externals.io/message/76530#76531 · In reply to: #76530 > As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add deprecation warnings and such to help people prepare for 7. The updated multiple default blocks in a switch statement proposes exactly this. Even if PHP 5.7 doesn't have any features I think it would make the transition to PHP 7 easier. --- ## #76532 — Andrea Faulds — 2014-08-15T01:10:02+00:00 URL: https://externals.io/message/76530#76532 · In reply to: #76531 > > […] > > The updated multiple default blocks in a switch statement proposes > exactly this. Even if PHP 5.7 doesn't have any features I think it > would make the transition to PHP 7 easier. Right. The specification is a general motivation for 5.7 for me, actually. By specifying PHP we spot a lot of things that need fixing, and 5.7 is a good time to fix them or note that we’re going to fix them. That means we don’t have these loose ends lying around as specified behaviour for two or three years. It could also be the first version of PHP which would have the official specification and implementation released at the same time, I hope. :) -- Andrea Faulds http://ajf.me/ --- ## #76541 — Derick Rethans — 2014-08-15T09:25:18+00:00 URL: https://externals.io/message/76530#76541 · In reply to: #76530 > I’ve kept putting this off, but given the current “move phpng to > master” vote, I really can’t delay this any longer. > > It looks like PHP 7 is going to happen and phpng will be the base of > that. While we could move straight to PHP 7 after the release of PHP > 5.6, I think there is some merit in having one more 5.x release, > namely 5.7, which would follow our usual release process and come out > next year. Basically, you're wanting to give up hope on PHP 7 in one year *at the moment it is started*... I think that's a pretty big mistake to do this already. The momentum is here now, let's use it to get PHP 7 ready—instead of bogging ourselves down with a PHP 5.7. cheers, Derick --- ## #76542 — Pierre Joye — 2014-08-15T09:28:01+00:00 URL: https://externals.io/message/76530#76542 · In reply to: #76541 > > > > […] > > Basically, you're wanting to give up hope on PHP 7 in one year *at the > moment it is started*... I think that's a pretty big mistake to do this > already. The momentum is here now, let's use it to get PHP 7 > ready—instead of bogging ourselves down with a PHP 5.7. It is not going to be one year. This is insane to consider php7 as ng only. And we need 5.7 anyway to prepare 7, as stated numerous time already. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #76544 — Zeev Suraski — 2014-08-15T09:29:41+00:00 URL: https://externals.io/message/76530#76544 · In reply to: #76541 > -----Original Message----- > From: Derick Rethans [mailto:derick@php.net] > Sent: Friday, August 15, 2014 12:25 PM > To: Andrea Faulds > Cc: PHP internals > Subject: Re: [PHP-DEV] Let's make a 5.7 release > > > > > […] > > Basically, you're wanting to give up hope on PHP 7 in one year *at the > moment it is started*... I think that's a pretty big mistake to do this > already. The > momentum is here now, let's use it to get PHP 7 ready—instead of bogging > ourselves down with a PHP 5.7. Exactly. Zeev --- ## #76549 — Ferenc Kovacs — 2014-08-15T10:43:14+00:00 URL: https://externals.io/message/76530#76549 · In reply to: #76541 > > > > […] > > Basically, you're wanting to give up hope on PHP 7 in one year *at the > moment it is started*... I think that's a pretty big mistake to do this > already. The momentum is here now, let's use it to get PHP 7 > ready—instead of bogging ourselves down with a PHP 5.7. > we don't have a single instance where we were able to deliver a minor release under a year, and I'm fairly sure that 7.0 will see more proposed features/changes as any previous minor, because there are stuff which can only happen in a major version. More changes(both in numbers and in impact) will need more time to stabilize, so I think that the one year roadmap for 7.0 is unrealistic. You seem to be arguing that 5.7 would pull away resources from 7.0, but I'm fairly sure that 5.7 would be the smallest of the 5.x minor versions for two reasons: we are getting better with not letting BC breaks slip in in minors plus working on a major version is much more interesting as you have less restrictions, so I think that 5.7 will/would be only to make the bed for 7.0, mostly introducing E_DEPRECATEDs and maybe a handfull of small features. I think that there is no reason to give up our current release policy and roadmap, and bet everything on PHP7, we don't lose anything with keeping 5.7. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #76550 — Pierre Joye — 2014-08-15T11:11:36+00:00 URL: https://externals.io/message/76530#76550 · In reply to: #76549 > > > > > […] > > we don't have a single instance where we were able to deliver a minor > release under a year, and I'm fairly sure that 7.0 will see more proposed > features/changes as any previous minor, because there are stuff which can > only happen in a major version. > More changes(both in numbers and in impact) will need more time to > stabilize, so I think that the one year roadmap for 7.0 is unrealistic. > You seem to be arguing that 5.7 would pull away resources from 7.0, but I'm > fairly sure that 5.7 would be the smallest of the 5.x minor versions for > two reasons: we are getting better with not letting BC breaks slip in in > minors plus working on a major version is much more interesting as you have > less restrictions, so I think that 5.7 will/would be only to make the bed > for 7.0, mostly introducing E_DEPRECATEDs and maybe a handfull of small > features. > I think that there is no reason to give up our current release policy and > roadmap, and bet everything on PHP7, we don't lose anything with keeping > 5.7. I cannot agree more with you here. And the delay something like bundling opcache needed almost 300% more time than what was promised. I won't even imagine what phpng will be in we rush it. Cheers, Pierre --- ## #76552 — Levi Morrison — 2014-08-15T13:39:37+00:00 URL: https://externals.io/message/76530#76552 I'm not completely sure about others in this thread, but my personal view is that PHP 5.7 should be released at around the same time as PHP 7. It should contain `E_DEPRECATED` warnings where applicable, such as proposed in the multiple default arguments RFC. I've also heard talk of removing some features in PHP 7 that are currently E_STRICT; in this case we would also move them to `E_DEPRECATED` in PHP 5.7. In summary, I think PHP 5.7 should primarily contain deprecations to ease the transition to 7, and should not take significant resources away from PHP 7. --- ## #76553 — Andrea Faulds — 2014-08-15T13:53:52+00:00 URL: https://externals.io/message/76530#76553 · In reply to: #76549 > > > > […] > > we don't have a single instance where we were able to deliver a minor > release under a year, and I'm fairly sure that 7.0 will see more proposed > features/changes as any previous minor, because there are stuff which can > only happen in a major version. > More changes(both in numbers and in impact) will need more time to > stabilize, so I think that the one year roadmap for 7.0 is unrealistic. > You seem to be arguing that 5.7 would pull away resources from 7.0, but I'm > fairly sure that 5.7 would be the smallest of the 5.x minor versions for > two reasons: we are getting better with not letting BC breaks slip in in > minors plus working on a major version is much more interesting as you have > less restrictions, so I think that 5.7 will/would be only to make the bed > for 7.0, mostly introducing E_DEPRECATEDs and maybe a handfull of small > features. > I think that there is no reason to give up our current release policy and > roadmap, and bet everything on PHP7, we don't lose anything with keeping > 5.7. I can’t agree more with this, you’ve put it better than I did. -- Andrea Faulds http://ajf.me/ --- ## #76554 — Levi Morrison — 2014-08-15T14:03:57+00:00 URL: https://externals.io/message/76530#76554 · In reply to: #76552 > proposed in the multiple default arguments RFC. Sorry, multiple default blocks in a switch statement RFC. --- ## #76555 — Sebastian Bergmann — 2014-08-15T14:51:02+00:00 URL: https://externals.io/message/76530#76555 · In reply to: #76530 Am 15.08.2014 um 02:48 schrieb Andrea Faulds: > As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add > deprecation warnings and such to help people prepare for 7. If the only changes that PHP 5.7 introduces (as compared to PHP 5.6) are deprecation warnings for features removed in PHP 7 then I am all for having PHP 5.7. With regard to the scope of PHP 7, I think it would be great to limit ourselves to "infrastructure" improvements (new executor from PHPNG, AST-based compiler (plus userland extension that provides access to the AST) from Nikita) and cleanup (removal of deprecated features). This cleaned up platform would be a great foundation for introducing new features in PHP 7.1. --- ## #76556 — Andrea Faulds — 2014-08-15T14:53:01+00:00 URL: https://externals.io/message/76530#76556 · In reply to: #76555 > With regard to the scope of PHP 7, I think it would be great to limit > ourselves to "infrastructure" improvements (new executor from PHPNG, > AST-based compiler (plus userland extension that provides access to > the AST) from Nikita) and cleanup (removal of deprecated features). > This cleaned up platform would be a great foundation for introducing new > features in PHP 7.1. I’m not sure that’s a good idea. Certain new features would require breaking backwards-compatibility, which we can’t do in minor releases. -- Andrea Faulds http://ajf.me/ --- ## #76571 — David Soria Parra — 2014-08-15T22:19:55+00:00 URL: https://externals.io/message/76530#76571 · In reply to: #76549 > --001a11c1258a38c82a0500a8b070 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > we don't have a single instance where we were able to deliver a minor > release under a year, and I'm fairly sure that 7.0 will see more proposed > features/changes as any previous minor, because there are stuff which can > only happen in a major version. > More changes(both in numbers and in impact) will need more time to > stabilize, so I think that the one year roadmap for 7.0 is unrealistic. > You seem to be arguing that 5.7 would pull away resources from 7.0, but I'm > fairly sure that 5.7 would be the smallest of the 5.x minor versions for > two reasons: we are getting better with not letting BC breaks slip in in > minors plus working on a major version is much more interesting as you have > less restrictions, so I think that 5.7 will/would be only to make the bed > for 7.0, mostly introducing E_DEPRECATEDs and maybe a handfull of small > features. > I think that there is no reason to give up our current release policy and > roadmap, and bet everything on PHP7, we don't lose anything with keeping > 5.7. My main concern with this is that it's php6 all over again. A PHP 7 where everyone waits and pushes all their new stuff in their but nobody actually ever releases because "one more feature" or they are too busy maintaining the old series. I personally feel PHP7 will be stale and slowly die if we do a 5.7, or who wants to even further support multiple branches with different APIs (didn't we learn anything from PHP 6?). --- ## #76572 — Pierre Joye — 2014-08-15T22:43:29+00:00 URL: https://externals.io/message/76530#76572 · In reply to: #76571 (didn't > we learn anything from PHP 6?). I did. And with opcache. Both with hypothetical deadlines based on arbitrary random facts about the status or stability. Here we have two issues, whether or not we need a 5.x to prepare 7 and if one year Dev time is enough. Let be realistic instead of yet again trying to achieve impossible goals, or think we achieved them and release something we won't be able to change for the next decade. --- ## #76573 — David Soria Parra — 2014-08-15T22:49:32+00:00 URL: https://externals.io/message/76530#76573 · In reply to: #76572 > --001a1133979e094b370500b2c0a9 > Content-Type: text/plain; charset=UTF-8 > > > (didn't > > […] > > I did. And with opcache. Both with hypothetical deadlines based on > arbitrary random facts about the status or stability. > > Here we have two issues, whether or not we need a 5.x to prepare 7 and if > one year Dev time is enough. > > Let be realistic instead of yet again trying to achieve impossible goals, > or think we achieved them and release something we won't be able to change > for the next decade. Let me summerize a few things that have come up: (1) phpng doesn't justify PHP7 It does. It's a complete new engine. It has performance improvements. Where do you draw the line of what justifies a PHP 7? It's a major BC break and we needd a major version for it (2) We can't get it stable. That's to be debated. The question is, with what we have now can we stabelize that? Modern release process try to minimize the delta between versions as much as possible. The only reason why we do a 7 instead of 5.7 is becuse we have a BC break to serve. In fact we do want to serve it as soon as possible. That we ensure people have time to move their products over. Most importantly we keep have to keep the divergance between branches as small as possible to make moving to new versions easier for our users and easier for us to maintain all the open branches (which are too many already). So the only question remains: Can we do PHP 7 with exactly ONLY the features we have in the next 12 months? --- ## #76574 — Pierre Joye — 2014-08-15T22:52:19+00:00 URL: https://externals.io/message/76530#76574 · In reply to: #76573 > > > […] > > Let me summerize a few things that have come up: > > (1) phpng doesn't justify PHP7 > It does. It's a complete new engine. It has performance improvements. Where > do you draw the line of what justifies a PHP 7? It's a major BC break and we > needd a major version for it No it does not. Even if it would do, that's not something I can live with in the next 10 years. As I repeatedly said, with explanations why. -- Pierre @pierrejoye | http://www.libgd.org --- ## #76575 — Wim Godden — 2014-08-15T23:04:22+00:00 URL: https://externals.io/message/76530#76575 · In reply to: #76572 > Here we have two issues, whether or not we need a 5.x to prepare 7 and if > one year Dev time is enough. IMHO, that'll depend on which feature will be added/changed/refactored for 7. I might have missed that discussion, but so far I haven't seen a wishlist or anything similar appear. It might be time for everyone to sum up what they'd like to see happen for 7, so it can be discussed and we have some idea of how big the task of developing 7 is. There's no point discussing timeframes if you don't know what needs to be done within the timeframe. (Again : maybe I missed that 7 feature thread. In that case, never mind ;-) ) Wim --- ## #76576 — Christoph Becker — 2014-08-15T23:33:28+00:00 URL: https://externals.io/message/76530#76576 · In reply to: #76575 Wim Godden wrote: > > > […] > > IMHO, that'll depend on which feature will be added/changed/refactored > for 7. I might have missed that discussion, but so far I haven't seen a > wishlist or anything similar appear. There is (which might be renamed, BTW). -- Christoph M. Becker --- ## #76577 — Yasuo Ohgaki — 2014-08-15T23:51:05+00:00 URL: https://externals.io/message/76530#76577 · In reply to: #76530 Hi all, > I’ve kept putting this off, but given the current “move phpng to master” > vote, I really can’t delay this any longer. > > It looks like PHP 7 is going to happen and phpng will be the base of that. > While we could move straight to PHP 7 after the release of PHP 5.6, I think > there is some merit in having one more 5.x release, namely 5.7, which would > follow our usual release process and come out next year. > > PHP 7, as a major release, is likely to take much longer than a usual > minor release. While some people might think one year is realistic, I > highly doubt that, as I suspect phpng will not be the only new feature PHP > 7 will contain. Major releases come with major changes, and I suspect some > others will crop up, and these might delay the release. Because it will > probably take two to three years, having a minor release in the meantime > means userland developers won’t be starved of new features which don’t need > to be in a major release and could be in a minor. > > Another point is that PHP 7 is probably going to break > backwards-compatibility more significantly than minors would. For starters, > phpng will break extension compatibility, and new proposals are likely to > break userland compatibility as well. By making 5.7 happen, developers will > have more time to switch to PHP 7 and can keep their existing codebases for > longer. > > As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add > deprecation warnings and such to help people prepare for 7. > > Finally, it is a fallback. If we do end up targeting 7 to come out next > year, then if serious issues cause delays to 7, we will have a less > ambitious and working new release to fall back on. > > I should clarify that I don’t wish to delay phpng at all, I am very much > in favour of it and excited about it, nor do I expect this to delay it. We > can simply work on two releases at once: PHP 7, an ambitious BC-breaking > release to come out later, and PHP 5.7, a safe, non-breaking release that > will come out next year with the usual schedule. > +1 Having 5.7 would be nicer for users and developers. Let's have 5.7 and master branch for PHP7 now. I would like to have +1 year dev time for PHP7. However, it may be good idea to release 5.7 and 7.0 at the same time. I suppose big changes may be implemented in 7.x. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #76578 — Jonathan Wage — 2014-08-15T23:57:21+00:00 URL: https://externals.io/message/76530#76578 I agree with Derick, Zeev and Sebastian. It seems more economical at this point for everyone to join together and focus our efforts on PHP 7. I also think we should be bold and target the PHP 7 release for one year from now. If everyone gets on board and works towards the same goal it is possible. - Jon On Fri, Aug 15, 2014 at 5:30 AM, Sebastian Bergmann wrote: > Am 15.08.2014 um 11:25 schrieb Derick Rethans: > > […] > > +1 > > -- > > > > -- Connect with me on *http://twitter.com/jwage* Wim Godden wrote: > > > […] > >There is (which might be renamed, BTW). And most of these things have to be added to PHP 7 before the feature freeze. 'one year Dev time' might actually be only 10 months. Feature freeze for 5.6.0 was mid June... Jan --- ## #76580 — Pierre Joye — 2014-08-16T03:20:51+00:00 URL: https://externals.io/message/76530#76580 · In reply to: #76579 > > Christoph Becker in php.internals (Sat, 16 Aug 2014 01:33:28 +0200): > > […] and if > > […] > > And most of these things have to be added to PHP 7 before the feature > freeze. 'one year Dev time' might actually be only 10 months. Feature > freeze for 5.6.0 was mid June... More 7-8 months... --- ## #76581 — Pierre Joye — 2014-08-16T03:28:53+00:00 URL: https://externals.io/message/76530#76581 · In reply to: #76578 > > I agree with Derick, Zeev and Sebastian. > > It seems more economical at this point for everyone to join together and > focus our efforts on PHP 7. Short term? Maybe, if we forget that the period will be more 6-7 months. Long term? An economical disaster. Cheers, Pierre --- ## #76583 — Sebastian Bergmann — 2014-08-16T07:02:59+00:00 URL: https://externals.io/message/76530#76583 · In reply to: #76571 Am 16.08.2014 um 00:19 schrieb David Soria Parra: > My main concern with this is that it's php6 all over again. That is my fear, too. --- Next page: https://externals.io/message/76530.md?page=2