# [RFC] PHP 5.7 - Thread: https://externals.io/message/79679 - Original archive: https://news-web.php.net/php.internals/79679 - Started by Andrea Faulds on 2014-12-16T00:09:32+00:00 - Messages: 57 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/79679.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 --- ## #79679 — Andrea Faulds — 2014-12-16T00:09:32+00:00 URL: https://externals.io/message/79679#79679 Good evening, There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. The hope is that we can put this to a vote in 2 weeks’ time and settle the matter, just as we did with the PHP 6/7 name vote, although perhaps slightly less messily this time. ;) The RFC can be found here: https://wiki.php.net/rfc/php57 Thanks! -- Andrea Faulds http://ajf.me/ --- ## #79680 — Adam Harvey — 2014-12-16T00:15:48+00:00 URL: https://externals.io/message/79679#79680 · In reply to: #79679 > The RFC can be found here: https://wiki.php.net/rfc/php57 Thanks for the taking the initiative on this. On timing: I think we should release 5.7 in August (12 months after 5.6), rather than lining it up with 7.0. This gives us the opportunity to then focus our attention on 7.0 entirely for the crucial RC phase of that release. Given the limited scope of 5.7, we shouldn't need as long a testing cycle. Adam --- ## #79681 — Andrea Faulds — 2014-12-16T00:20:21+00:00 URL: https://externals.io/message/79679#79681 · In reply to: #79680 Hi Adam, > > > > > […] > > Thanks for the taking the initiative on this. > > On timing: I think we should release 5.7 in August (12 months after > 5.6), rather than lining it up with 7.0. This gives us the opportunity > to then focus our attention on 7.0 entirely for the crucial RC phase > of that release. Given the limited scope of 5.7, we shouldn't need as > long a testing cycle. That’s a good point, it doesn’t actually have to line up with 7’s release and focus on 7.0 RC is crucial given the major changes. If others think this is a good idea, I’ll amend the RFC. Thanks! -- Andrea Faulds http://ajf.me/ --- ## #79684 — Kris Craig — 2014-12-16T01:19:21+00:00 URL: https://externals.io/message/79679#79684 · In reply to: #79681 > Hi Adam, > > > […] > > That’s a good point, it doesn’t actually have to line up with 7’s release > and focus on 7.0 RC is crucial given the major changes. > > If others think this is a good idea, I’ll amend the RFC. > > Thanks! > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > > > > +1 on this. I agree with Adam; it'd be better to line up 5.7 with the support timeline for 5.6 and just handle 7's timeline separately. --Kris --- ## #79685 — Xinchen Hui — 2014-12-16T04:07:02+00:00 URL: https://externals.io/message/79679#79685 · In reply to: #79679 > Good evening, > > There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. > I am wondering why we need that? no new features.... I think we can extend 5.6 release cycle to avoid that.. thanks > The hope is that we can put this to a vote in 2 weeks’ time and settle the matter, just as we did with the PHP 6/7 name vote, although perhaps slightly less messily this time. ;) > > The RFC can be found here: https://wiki.php.net/rfc/php57 > > Thanks! > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > > > -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #79688 — Andrea Faulds — 2014-12-16T05:51:20+00:00 URL: https://externals.io/message/79679#79688 · In reply to: #79685 Hi Xinchen, > > > > > […] > I am wondering why we need that? no new features…. The reasoning behind this is to encourage people to switch to PHP 7 if they want new features. > I think we can extend 5.6 release cycle to avoid that.. We could, but we wouldn’t be able to introduce deprecation notices in a 5.6 micro, so we’d need a new minor releases. Also, I failed to mention it in the RFC (will do so), but for any new reserved words in PHP 7, we should also reserve them in 5.7. Thanks. -- Andrea Faulds http://ajf.me/ --- ## #79690 — Levi Morrison — 2014-12-16T07:29:19+00:00 URL: https://externals.io/message/79679#79690 · In reply to: #79685 > > […] > I am wondering why we need that? no new features.... > > I think we can extend 5.6 release cycle to avoid that.. Extending the PHP 5.6 release cycle doesn't give an opportunity to raise different `E_STRICT` and `E_DEPRECATED` messages in preparation for PHP 7.0. This may or may not be something you value, but it's something I personally value. --- ## #79691 — Andrea Faulds — 2014-12-16T07:35:39+00:00 URL: https://externals.io/message/79679#79691 · In reply to: #79680 Hi everyone, > > > > > […] > > Thanks for the taking the initiative on this. > > On timing: I think we should release 5.7 in August (12 months after > 5.6), rather than lining it up with 7.0. This gives us the opportunity > to then focus our attention on 7.0 entirely for the crucial RC phase > of that release. Given the limited scope of 5.7, we shouldn't need as > long a testing cycle. > > > +1 on this. I agree with Adam; it'd be better to line up 5.7 with the support timeline for 5.6 and just handle 7's timeline separately. > I’ve updated the RFC to target August 2015 for release. This would mean it would come out a year after 5.6, and the RC phase would be half as PHP 7’s. > > > Also, I failed to mention it in the RFC (will do so), but for any new reserved words in PHP 7, we should also reserve them in 5.7. I’ve also updated the to note that reserved words in PHP 7 can be pre-reserved in PHP 5.7. Thanks for your comments! -- Andrea Faulds http://ajf.me/ --- ## #79693 — Matteo Beccati — 2014-12-16T07:52:08+00:00 URL: https://externals.io/message/79679#79693 · In reply to: #79685 > > > […] > I am wondering why we need that? no new features.... > > I think we can extend 5.6 release cycle to avoid that.. I tend to agree with Xinchen here. A new minor release just to introduce a few deprecation messages? It sounds like a lot of work (it also need to be maintained) for little gain. I think that doesn't also match the plans of other (accepted?) RFCs that were targeted for 5.7. I think I've seen it many times. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #79694 — Andrea Faulds — 2014-12-16T07:55:16+00:00 URL: https://externals.io/message/79679#79694 · In reply to: #79693 Hi Matteo, > > > > > […] > > I tend to agree with Xinchen here. A new minor release just to introduce a few deprecation messages? It sounds like a lot of work (it also need to be maintained) for little gain. There should be very little work necessary. Deprecations are easy, and the changeset from 5.6 should be tiny at best. The only significant extra work is the added year of maintenance for the PHP 5 line. > I think that doesn't also match the plans of other (accepted?) RFCs that were targeted for 5.7. I think I've seen it many times. Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation notices? I’m unaware of any. Thanks. -- Andrea Faulds http://ajf.me/ --- ## #79695 — Ferenc Kovacs — 2014-12-16T07:58:30+00:00 URL: https://externals.io/message/79679#79695 · In reply to: #79693 > > > > > […] > > I tend to agree with Xinchen here. A new minor release just to introduce a > few deprecation messages? It sounds like a lot of work (it also need to be > maintained) for little gain. > > I think that doesn't also match the plans of other (accepted?) RFCs that > were targeted for 5.7. I think I've seen it many times. > > > We already has one accepted RFC which targets 5.7, and as I mentioned before 5.7.0 wouldn't be featureless, but would contain the small self-contained features which are currently targeting 5.6.x. So 5.7.0 would be a minor version without new major features, but also no BC break, would allow us to make 5.6 more stable, and be a stepping stone for 7.0 with the deprecated errors. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #79696 — Andrea Faulds — 2014-12-16T08:00:04+00:00 URL: https://externals.io/message/79679#79696 · In reply to: #79695 Hey, > > > We already has one accepted RFC which targets 5.7, and as I mentioned before 5.7.0 wouldn't be featureless, but would contain the small self-contained features which are currently targeting 5.6.x. > So 5.7.0 would be a minor version without new major features, but also no BC break, would allow us to make 5.6 more stable, and be a stepping stone for 7.0 with the deprecated errors. That’s a benefit I hadn’t considered: people using distros are stuck on a specific micro, so anything added to 5.6.x they’ll be able to get with 5.7.0, right? -- Andrea Faulds http://ajf.me/ --- ## #79697 — Ferenc Kovacs — 2014-12-16T08:20:24+00:00 URL: https://externals.io/message/79679#79697 · In reply to: #79696 > > Hey, > > > […] > before 5.7.0 wouldn't be featureless, but would contain the small > self-contained features which are currently targeting 5.6.x. > > […] > no BC break, would allow us to make 5.6 more stable, and be a stepping > stone for 7.0 with the deprecated errors. > > That’s a benefit I hadn’t considered: people using distros are stuck on a > specific micro, so anything added to 5.6.x they’ll be able to get with > 5.7.0, right? > > yep. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #79702 — Lester Caine — 2014-12-16T08:59:54+00:00 URL: https://externals.io/message/79679#79702 · In reply to: #79690 > > […] > Extending the PHP 5.6 release cycle doesn't give an opportunity to > raise different `E_STRICT` and `E_DEPRECATED` messages in preparation for > PHP 7.0. This may or may not be something you value, but it's > something I personally value. +1 Leave 5.6 as a 'clean' version so stability is retained. 5.7 is an optional stepping stone to help upgrade code, but for users of frameworks will have their content migrated from an older platform to a clean PHP7 one. It is only those users who have personal code that need help migrating. 5.7 would have sub versions as particular problems are identified in the migration process rather than encumbering PHP7 with unnecessary bloat? -- 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 --- ## #79704 — Stanislav Malyshev — 2014-12-16T09:25:46+00:00 URL: https://externals.io/message/79679#79704 · In reply to: #79679 Hi! > There has been some debate about whether to make “PHP 5.7". I have > made a very simple RFC. It proposes a final minor version of PHP 5, > PHP 5.7, to be released at the same time as PHP 7, with no new > features whatsoever. > > The hope is that we can put this to a vote in 2 weeks’ time and > settle the matter, just as we did with the PHP 6/7 name vote, > although perhaps slightly less messily this time. ;) It'd be nice to describe what we have now for 5.7 - i.e. which deprecation messages and other warnings are on the agenda? Doesn't have to be the exclusive list but at least to give the idea what we're talking about. -- Stas Malyshev smalyshev@gmail.com --- ## #79709 — Matteo Beccati — 2014-12-16T10:52:49+00:00 URL: https://externals.io/message/79679#79709 · In reply to: #79694 > Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation notices? I’m unaware of any. I've tried to search the ML for such list of RFCs: https://wiki.php.net/rfc/gc_fn_pointer https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree) https://wiki.php.net/rfc/closure_apply https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6) https://wiki.php.net/rfc/intdiv https://wiki.php.net/rfc/session.user.return-value maybe others too, but I got bored ;) Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #79710 — Andrea Faulds — 2014-12-16T11:03:16+00:00 URL: https://externals.io/message/79679#79710 · In reply to: #79709 Hey Matteo, > > > > > […] > > I've tried to search the ML for such list of RFCs: > > https://wiki.php.net/rfc/gc_fn_pointer > https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree) > https://wiki.php.net/rfc/closure_apply > https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6) > https://wiki.php.net/rfc/intdiv > https://wiki.php.net/rfc/session.user.return-value > > maybe others too, but I got bored ;) I wrote the Closure::call() and `intdiv()` RFCs. Truth be told, they both targeted master, not a specific PHP version. master has become PHP 7, so whatever the wording of them said, they really target PHP 7 now. They were written back before the whole PHP 7/phpng thing when I didn’t know whether we were going to go straight to PHP 7 or whether there’d be another minor and then PHP 7 a year or two after. Now we’re going straight to PHP 7 - the 5.7 proposed wouldn’t be an exception to that, as 5.7 would have no new features and be released around the same time. It’s not, well, the 5.7 I had in mind when I wrote those RFCs. Filtered `unserialize()` and 64-bit pack/unpack targeted 5.6 micro releases, not 5.7. I don’t really know about the session handling and GC ones. -- Andrea Faulds http://ajf.me/ --- ## #79712 — Andrea Faulds — 2014-12-16T11:10:55+00:00 URL: https://externals.io/message/79679#79712 · In reply to: #79704 Hey Stas, > > > > […] > > It'd be nice to describe what we have now for 5.7 - i.e. which > deprecation messages and other warnings are on the agenda? Doesn't have > to be the exclusive list but at least to give the idea what we're > talking about. At the moment, there’s Levi’s RFC to disallow multiple defaults in switch statements, which adds an `E_DEPRECATED` notice in 5.7. I don’t think there’s anything else. It might be worth adding some sort of warning for Nikita’s Remove alternative PHP tags RFC. Perhaps also for the Integer Semantics RFC, warning that shifts by negative numbers of bits will be disallowed in PHP 7, or for the Fix list() behaviour inconsistency RFC since strings won’t work in list() now. -- Andrea Faulds http://ajf.me/ --- ## #79714 — Matteo Beccati — 2014-12-16T11:16:56+00:00 URL: https://externals.io/message/79679#79714 · In reply to: #79712 Hi Andrea, > > […] > > At the moment, there’s Levi’s RFC to disallow multiple defaults in switch statements, which adds an `E_DEPRECATED` notice in 5.7. > > I don’t think there’s anything else. It might be worth adding some sort of warning for Nikita’s Remove alternative PHP tags RFC. Perhaps also for the Integer Semantics RFC, warning that shifts by negative numbers of bits will be disallowed in PHP 7, or for the Fix list() behaviour inconsistency RFC since strings won’t work in list() now. I was initially very much in favour of a 5.7 release, but given the current lack of big BC breaks I'm not so sure. I can even run a dinosaur like Revive on PHP7! If the list of BC breaks grows (e.g. PHP4 constructors -- which I seriously hope doesn't pass -- or other big / evil ones), then I could change my mind once again, but as of now I personally see little gain in a PHP 5.7. That said, I think an RFC is good, but we should run the vote only when we know exactly when PHP7 is going to be, so that everyone can make an informed decision. Doing it now could be premature. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #79715 — Matteo Beccati — 2014-12-16T11:29:58+00:00 URL: https://externals.io/message/79679#79715 · In reply to: #79710 > I wrote the Closure::call() and `intdiv()` RFCs. Truth be told, they > both targeted master, not a specific PHP version. master has become > PHP 7, so whatever the wording of them said, they really target PHP 7 > now. They were written back before the whole PHP 7/phpng thing when I > didn’t know whether we were going to go straight to PHP 7 or whether > there’d be another minor and then PHP 7 a year or two after. Now > we’re going straight to PHP 7 - the 5.7 proposed wouldn’t be an > exception to that, as 5.7 would have no new features and be released > around the same time. It’s not, well, the 5.7 I had in mind when I > wrote those RFCs. This is what I meant when I previously mentioned seeing RFCs targeting 5.7. I understand what you say and I do wholeheartedly agree with you. However if one would have to strictly follow what has been voted, such features should be backported to whatever becomes 5.7, if any. Perhaps the 5.7 RFC could explicitly states what is (not) going to happen wrt those RFCs. > I don’t really know about the session handling and GC ones Likewise. And there might be more that I haven't looked up. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #79716 — Andrea Faulds — 2014-12-16T11:33:09+00:00 URL: https://externals.io/message/79679#79716 · In reply to: #79715 Hey Matteo, > > > This is what I meant when I previously mentioned seeing RFCs targeting 5.7. I understand what you say and I do wholeheartedly agree with you. > > However if one would have to strictly follow what has been voted, such features should be backported to whatever becomes 5.7, if any. Perhaps the 5.7 RFC could explicitly states what is (not) going to happen wrt those RFCs. I think it’s pretty clear in stating 5.7 will have no new features. Thanks, -- Andrea Faulds http://ajf.me/ --- ## #79723 — Zeev Suraski — 2014-12-16T14:09:49+00:00 URL: https://externals.io/message/79679#79723 · In reply to: #79696 > -----Original Message----- > From: Andrea Faulds [mailto:ajf@ajf.me] > Sent: Tuesday, December 16, 2014 10:00 AM > To: Ferenc Kovacs > Cc: Matteo Beccati; Xinchen Hui; PHP Internals > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > Hey, > > > […] > before 5.7.0 wouldn't be featureless, but would contain the small self- > contained features which are currently targeting 5.6.x. > > […] > BC break, would allow us to make 5.6 more stable, and be a stepping stone > for 7.0 with the deprecated errors. > > That’s a benefit I hadn’t considered: people using distros are stuck on a > specific micro, so anything added to 5.6.x they’ll be able to get with > 5.7.0, > right? I'm missing what benefit this gives us. Distros lock the version (all 3 digits) for a particular distro version; At the same time, when a new version of the distro comes out, there are no version restrictions of any kind. So for a given distro that uses 5.6.8 (as an example), upgrading to 5.6.9 or 5.7.0 or even 7.0.0 is equally forbidden within the same distro version, and equally allowed within a new distro version. Zeev --- ## #79724 — Zeev Suraski — 2014-12-16T15:23:10+00:00 URL: https://externals.io/message/79679#79724 · In reply to: #79690 > -----Original Message----- > From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On > Behalf Of Levi Morrison > Sent: Tuesday, December 16, 2014 9:29 AM > To: Xinchen Hui > Cc: Andrea Faulds; PHP Internals > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > > […] > made a very simple RFC. It proposes a final minor version of PHP 5, PHP > 5.7, > to be released at the same time as PHP 7, with no new features whatsoever. > > […] > > Extending the PHP 5.6 release cycle doesn't give an opportunity to raise > different `E_STRICT` and `E_DEPRECATED` messages in preparation for PHP 7.0. > This may or may not be something you value, but it's something I > personally > value. I don't see why we'd need new E_STRICT's, but what stops us from adding `E_DEPRECATED` to 5.6.x? I think the likelihood of getting these notices in the hands of people goes way higher if we put it into 5.6.x, which will be perceived as a bug-fix release, than a 5.7.0, which will be perceived as a feature release. Zeev --- ## #79725 — Ferenc Kovacs — 2014-12-16T16:10:33+00:00 URL: https://externals.io/message/79679#79725 · In reply to: #79704 On Tue, Dec 16, 2014 at 10:25 AM, Stanislav Malyshev wrote: > > Hi! > > > […] > > It'd be nice to describe what we have now for 5.7 - i.e. which > deprecation messages and other warnings are on the agenda? Doesn't have > to be the exclusive list but at least to give the idea what we're > talking about. > Just an initial list, feel free to extend it: - we could add an `E_DEPRECATED` for zpp overflow: https://wiki.php.net/rfc/zpp_fail_on_overflow - if we could trigger `E_DEPRECATED` for function foo($x,$x) {} which is now a compile error thanks to https://wiki.php.net/phpng that would be nice - if we could cover some of the BC breaks with `E_DEPRECATED` from https://wiki.php.net/rfc/uniform_variable_syntax#backward_incompatible_changes that would be nice, but not sure if feasible. - if we could trigger `E_DEPRECATED` for list()-ing a string which will be removed in 7.0(https://wiki.php.net/rfc/fix_list_behavior_inconsistency) that would be nice. - `E_DEPRECATED` for the alternative php tags which will be removed with 7.0(https://wiki.php.net/rfc/remove_alternative_php_tags). - merge https://github.com/php/php-src/pull/807 for adding `E_DEPRECATED` for multiple default labels in switch. - maybe we could add an `E_DEPRECATED` for https://wiki.php.net/rfc/session.user.return-value to notify authors of custom session handlers( https://wiki.php.net/rfc/session.user.return-value) - please note that the vote for this change was in favour for changing it in 5.7, so if we don't overrule the decision, we don't add the deprecated message, but the BC break instead. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #79726 — Ferenc Kovacs — 2014-12-16T16:15:09+00:00 URL: https://externals.io/message/79679#79726 · In reply to: #79710 > > Hey Matteo, > > > […] > deprecation notices? I’m unaware of any. > > […] > > I wrote the Closure::call() and `intdiv()` RFCs. Truth be told, they both > targeted master, not a specific PHP version. master has become PHP 7, so > whatever the wording of them said, they really target PHP 7 now. They were > written back before the whole PHP 7/phpng thing when I didn’t know whether > we were going to go straight to PHP 7 or whether there’d be another minor > and then PHP 7 a year or two after. Now we’re going straight to PHP 7 - the > 5.7 proposed wouldn’t be an exception to that, as 5.7 would have no new > features and be released around the same time. It’s not, well, the 5.7 I > had in mind when I wrote those RFCs. > > could you please update the rfc and the intdiv page to move the target version to 7.0? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- Next page: https://externals.io/message/79679.md?page=2