Re: [PHP-DEV] [RFC] PHP 5.7
On 17/12/14 00:45, Andrea Faulds wrote: Hi Pierre, On 16 Dec 2014, at 23:42, Pierre Joye pierre@gmail.com wrote: On Dec 17, 2014 4:19 AM, Andrea Faulds a...@ajf.me wrote: Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a year sounds like a better solution. If others agree, I might withdraw this RFC. Please do not. I’m not considering dropping the RFC because of opposition. Rather, I think that suggestion is actually better than having a 5.7 release. I'd definitely be in favor of concentrating on 7.0 and rather have external supportive tools instead of an 5.7 release. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, 16 Dec 2014, Ferenc Kovacs wrote: - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new features cancels point number one What else ? Do nothing is still (IMHO) the most sensible option IMHO. We're not seeing major compatibility breakages in 7.0 (at least not at this time), to the level that upgrading through some middle version is really all that necessary. we don't have much or really big ones(yet), we have a couple of nasty ones (eg. doesn't blow up, but behaves differently, check the mails from Derick complaining about those). Those should never have made it into PHP 7 at all. It's like a big fuck you to users. and there are a couple ones upcoming/likely to make it through: https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 I think we should bump up the granularity of the voting options there. As some I think are ok, for example: - dl on fpm-fcgi (since PHP 5.3) But others are not: - CN_match and SNI_server_name stream context option (since PHP 5.6; use peer_name instead) [TODO] The one option that could be relevant to these scenarios is a separate analysis tool, but it's much more difficult to pull off, and I don't think the level of breakage (as it appears right now) justifies the effort. fortunately we already have a couple of those for some of the nasty changes like https://gist.github.com/nikic/ffd019ef78b72934c7cc for finding code which would be affected by the behavior change of https://wiki.php.net/rfc/uniform_variable_syntax I do think that while those kind of extra steps are not mandatory per se, but they help a lot when convincing people to jump the ship and upgrade. I would go as far as making it mandatory if you change bahaviour of existing syntax that can't be detected through a simple php -l. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] PHP 5.7
could you clarify one thing for me? from that sentence it seems that you aren't really against having small new features (as those are already happened/happening in 5.6.x and you did not mention that you have a problem with that) but you think that there would be more/bigger features happening if there would be an 5.7 version? I’m opposed to having a 5.7 release that has new features on top of 5.6.x. There should be no new feature release in the 5.x line beyond 5.6.x. I also think we should minimize any new work on 5.6.x as much as possible, and focus all of our efforts on 7.0.
Re: [PHP-DEV] [RFC] PHP 5.7
Am 17.12.2014 um 15:54 schrieb Zeev Suraski: I’m opposed to having a 5.7 release that has new features on top of 5.6.x. Same here; 5.7 should only add deprecations etc. and must not add new features. I also think we should minimize any new work on 5.6.x as much as possible, and focus all of our efforts on 7.0. PHP 5.6.X must not get any more new features and should only receive bug fixes. The only real work I see for PHP 5.7 is to decide which deprecations etc. to add. The actual implementation of those should be trivial. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hey, On 16 Dec 2014, at 07:58, Ferenc Kovacs tyr...@gmail.com wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 9:00 AM, Andrea Faulds a...@ajf.me wrote: Hey, On 16 Dec 2014, at 07:58, Ferenc Kovacs tyr...@gmail.com wrote: 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? yep. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] PHP 5.7
On 16/12/14 07:29, Levi Morrison wrote: 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.. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On 16/12/2014 08:55, Andrea Faulds wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hey Matteo, On 16 Dec 2014, at 10:52, Matteo Beccati p...@beccati.com wrote: On 16/12/2014 08:55, Andrea Faulds wrote: 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 ;) 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hey Stas, On 16 Dec 2014, at 09:25, Stanislav Malyshev smalys...@gmail.com wrote: 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. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hi Andrea, On 16/12/2014 12:10, Andrea Faulds wrote: 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. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On 16/12/2014 12:03, Andrea Faulds wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hey Matteo, On 16 Dec 2014, at 11:29, Matteo Beccati p...@beccati.com wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] PHP 5.7
-Original Message- From: Andrea Faulds [mailto:a...@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, On 16 Dec 2014, at 07:58, Ferenc Kovacs tyr...@gmail.com wrote: 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] PHP 5.7
-Original Message- From: morrison.l...@gmail.com [mailto:morrison.l...@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 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.. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 10:25 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
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.
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
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 12:03 PM, Andrea Faulds a...@ajf.me wrote: Hey Matteo, On 16 Dec 2014, at 10:52, Matteo Beccati p...@beccati.com wrote: On 16/12/2014 08:55, Andrea Faulds wrote: 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 ;) 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
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 12:33 PM, Andrea Faulds a...@ajf.me wrote: Hey Matteo, On 16 Dec 2014, at 11:29, Matteo Beccati p...@beccati.com wrote: 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. I don't think that we have a consensus on that yet, I would put that up for voting, but I do agree that there shouldn't be any major features like what we used to have in a minor version(and I can understand the reasoning from Zeev to even push the small features to 7.0 instead so people have more reason to upgrade). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 4:23 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: morrison.l...@gmail.com [mailto:morrison.l...@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 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.. 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. as you mentioned distros lock in to a specific micro version, so if we introduce this deprecated messages in random micro version, we make it less likely for the users to stumble upon those deprecated messages and it will be also harder for us to communicate the upgrade path: compare: okay, you only have to install PHP 5.7 check out the deprecated messages in your error logs, fix those and you are ready to upgrade to 7.0 vs okay, so install 5.6, but make sure that it is = 5.6.x, except for distro Z, because they bumped the version but only backported the security fixes but did not include the last deprecated message and if you fixed those deprecated messages from your error log, you are ready to upgrade to 7.0. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] PHP 5.7
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.. 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? Changing which errors and warnings are emitted in a patch release will likely fill up some unsuspecting user's HDD, and for people writing their own error handlers it may also mess them up. I'd much rather see the change happen in a minor version. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
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. Support in general has been overwhelmingly in favor of removing PHP 4 constructors. It should go to vote soonish and then we'll have a better idea. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] PHP 5.7
as you mentioned distros lock in to a specific micro version, so if we introduce this deprecated messages in random micro version, we make it less likely for the users to stumble upon those deprecated messages and it will be also harder for us to communicate the upgrade path: compare: okay, you only have to install PHP 5.7 check out the deprecated messages in your error logs, fix those and you are ready to upgrade to 7.0 vs okay, so install 5.6, but make sure that it is = 5.6.x, except for distro Z, because they bumped the version but only backported the security fixes but did not include the last deprecated message and if you fixed those deprecated messages from your error log, you are ready to upgrade to 7.0. [Zeev] Distros don’t bump the version number when they backport patches from newer versions. It stays the same, which is why I don’t think there’s any difference between the two as far as communications is concerned. It’s really ‘Upgrade to 5.7’ vs. ‘Upgrade to 5.6.12 or later’ – both messages by the way irrelevant to distro users (which have little or no control over the version of PHP they’re using, unless they break away from the standard distro PHP). The people we really talk about are the people they build their own or otherwise obtain non-standard-distro binaries. For them, I do believe a jump to 5.7.x will be psychologically bigger than a hop to a newer 5.6.x version.
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 5:44 PM, Zeev Suraski z...@zend.com wrote: as you mentioned distros lock in to a specific micro version, so if we introduce this deprecated messages in random micro version, we make it less likely for the users to stumble upon those deprecated messages and it will be also harder for us to communicate the upgrade path: compare: okay, you only have to install PHP 5.7 check out the deprecated messages in your error logs, fix those and you are ready to upgrade to 7.0 vs okay, so install 5.6, but make sure that it is = 5.6.x, except for distro Z, because they bumped the version but only backported the security fixes but did not include the last deprecated message and if you fixed those deprecated messages from your error log, you are ready to upgrade to 7.0. [Zeev] Distros don’t bump the version number when they backport patches from newer versions. It stays the same, which is why I don’t think there’s any difference between the two as far as communications is concerned. It’s really ‘Upgrade to 5.7’ vs. ‘Upgrade to 5.6.12 or later’ – both messages by the way irrelevant to distro users (which have little or no control over the version of PHP they’re using, unless they break away from the standard distro PHP). The people we really talk about are the people they build their own or otherwise obtain non-standard-distro binaries. For them, I do believe a jump to 5.7.x will be psychologically bigger than a hop to a newer 5.6.x version. my point was that it is easier to say that you can use whatever 5.7 release to make sure you are fine to upgrade to 7.0 versus depending on a specific 5.6 micro version. but you are right that most distros don't bump the upstream version but suffix it with their own revision number, and bump that when backporting bug/security fixes. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
RE: [PHP-DEV] [RFC] PHP 5.7
On Dec 16, 2014 9:10 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Andrea Faulds [mailto:a...@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, On 16 Dec 2014, at 07:58, Ferenc Kovacs tyr...@gmail.com wrote: 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? 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. And given that many distros have a faster adoption rate, many will adopt 5.7, with notifications for the 7 changes, in their next release as they may be more looking for 6.1 than 6.0. To support this fact, see the recent adoption rate of all major versions since we adopted the release process RFC. One of its goal has been achieved.
RE: [PHP-DEV] [RFC] PHP 5.7
On Dec 16, 2014 10:23 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: morrison.l...@gmail.com [mailto:morrison.l...@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 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.. 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? We do not allow them or we try to avoid them by all means. 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. And what will be the work load difference then? Zero. However it will introduce changes in a patch release that may not be expected as of our RFC. I am totally opposed to this idea.
Re: [PHP-DEV] [RFC] PHP 5.7
Hi! 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 ;) Didn't I hear no features? Most of these are features. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] PHP 5.7
On 16 December 2014 16:44:59 GMT, Zeev Suraski z...@zend.com wrote: as you mentioned distros lock in to a specific micro version, so if we introduce this deprecated messages in random micro version, we make it less likely for the users to stumble upon those deprecated messages and it will be also harder for us to communicate the upgrade path: compare: okay, you only have to install PHP 5.7 check out the deprecated messages in your error logs, fix those and you are ready to upgrade to 7.0 vs okay, so install 5.6, but make sure that it is = 5.6.x, except for distro Z, because they bumped the version but only backported the security fixes but did not include the last deprecated message and if you fixed those deprecated messages from your error log, you are ready to upgrade to 7.0. [Zeev] Distros don’t bump the version number when they backport patches from newer versions. It stays the same, which is why I don’t think there’s any difference between the two as far as communications is concerned. It’s really ‘Upgrade to 5.7’ vs. ‘Upgrade to 5.6.12 or later’ – both messages by the way irrelevant to distro users (which have little or no control over the version of PHP they’re using, unless they break away from the standard distro PHP). The people we really talk about are the people they build their own or otherwise obtain non-standard-distro binaries. For them, I do believe a jump to 5.7.x will be psychologically bigger than a hop to a newer 5.6.x version. If people stick with their distribution's cycle, then this is true. However, many distributions these days have active backport eco systems. You're unlikely to find, say, an Ubuntu PPA offering 5.6.12 to replace 5.6.3, but you're almost certain to find one porting 5.7.0 to that same distro release. I don't know for sure that more conservative distros like Red Hat would be similar, but it seems more likely than not that upgrade to 5.7 would be easier advice to follow than upgrade to 5.6.12. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On 16 December 2014 at 10:38, Stanislav Malyshev smalys...@gmail.com wrote: 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 ;) Didn't I hear no features? Most of these are features. True, but none of them have been accepted for _this_ 5.7. As Andrea said, her 5.7 RFCs simply used that as a placeholder for what is now 7.0, since that was the master version number at the time. The same is true of Sara's session return value RFC. The new pack and unpack formats are in 5.6 already, I believe, so wouldn't be new to 5.7. Secure unserialise was your RFC, so you tell us. :) The only one that's pending and actually applies here is the GC function pointer RFC. As co-proposer, I'd obviously like to see it in 5.7 as well (there's no user impact, it's so trivial it probably doesn't even qualify for copyright protection, and it's useful for profilers), but I'm happy to accept that it might be a casualty of the no features rule. In summary: our current state would allow us to have a no features rule and for it to make sense with what's already been accepted. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] PHP 5.7
Hi list, I think having a minor PHP version for the only sake of adding E_DEPRECATED is kind of pointless to be honest. Historically, PHP (or other languages for the matter, I'm thinking of python) minor versions have brought new features. Adding notices is not a reason for a new version imho. If what we want are notices, and helping people to migrate to PHP 7, then we can create tools for this. For example, python made a tool to help with the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if my memory serves right. The point of new versions is to include new features or bug fixes for the language, static analysis can be done with external tools. The fact that we'll have to maintain one more version is also not something to be taken lightly, especially when I see examples of how things progress in php-src. (I'm thinking about the recent contributor who gave up.) Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then it's another matter, and the lifetime of existing versions could be extended. Just my $0.02. Cheers, Florian Margaine
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine flor...@margaine.com wrote: Hi list, I think having a minor PHP version for the only sake of adding E_DEPRECATED is kind of pointless to be honest. Historically, PHP (or other languages for the matter, I'm thinking of python) minor versions have brought new features. Adding notices is not a reason for a new version imho. If what we want are notices, and helping people to migrate to PHP 7, then we can create tools for this. For example, python made a tool to help with the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if my memory serves right. The point of new versions is to include new features or bug fixes for the language, static analysis can be done with external tools. The fact that we'll have to maintain one more version is also not something to be taken lightly, especially when I see examples of how things progress in php-src. (I'm thinking about the recent contributor who gave up.) Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then it's another matter, and the lifetime of existing versions could be extended. Just my $0.02. That's a perfectly valid POV I share. So I sum-up and introduce the dilema : - We should push people to PHP7 , whatever the way - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, under release process that forbids that) - Rolling out a 5.7 with *just* Warnings-of-any-kind is silly, see the topic I just replied to which is valid to me - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new features cancels point number one What else ? Julien.Pauli
Re: [PHP-DEV] [RFC] PHP 5.7
Hey Florian, On 16 Dec 2014, at 19:55, Florian Margaine flor...@margaine.com wrote: Hi list, I think having a minor PHP version for the only sake of adding E_DEPRECATED is kind of pointless to be honest. Historically, PHP (or other languages for the matter, I'm thinking of python) minor versions have brought new features. Adding notices is not a reason for a new version imho. If what we want are notices, and helping people to migrate to PHP 7, then we can create tools for this. For example, python made a tool to help with the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if my memory serves right. The point of new versions is to include new features or bug fixes for the language, static analysis can be done with external tools. The fact that we'll have to maintain one more version is also not something to be taken lightly, especially when I see examples of how things progress in php-src. (I'm thinking about the recent contributor who gave up.) Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then it's another matter, and the lifetime of existing versions could be extended. Just my $0.02. Cheers, Florian Margaine Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a year sounds like a better solution. If others agree, I might withdraw this RFC. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine flor...@margaine.com wrote: Hi list, I think having a minor PHP version for the only sake of adding E_DEPRECATED is kind of pointless to be honest. Historically, PHP (or other languages for the matter, I'm thinking of python) minor versions have brought new features. Adding notices is not a reason for a new version imho. please be aware the not everybody agrees on the no new features rule, but from as I can tell most people seem to agree that no new major features should be included. in an ideal world those kind of E_DEPRECATED messages would be there already before we break or remove a function so there would be no reason for this discussion. because this isn't a case I think it is reasonable to have a discussion if it would worth to have another minor in the 5.x series to make the upgrading to 7.0 easier. my proposal was to stop adding minor features into 5.6, create an 5.7 where those can go and make sure that any(which is possible/feasible) BC break will be foretold via E_DEPRECATED. If what we want are notices, and helping people to migrate to PHP 7, then we can create tools for this. For example, python made a tool to help with the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if my memory serves right. The point of new versions is to include new features or bug fixes for the language, static analysis can be done with external tools. This is not the first time this idea came up, and some of the BC incompatible changes in PHP7 already have such tools to spot such usages or fix them automagically. The fact that we'll have to maintain one more version is also not something to be taken lightly, especially when I see examples of how things progress in php-src. (I'm thinking about the recent contributor who gave up.) I think it would be a bit more work, but not that much: 5.4 would stay in security fix mod until 5.7 is released, 5.5 and 5.6 would be put/kept in bugfix/security fix mode, new features would only target 5.7 and 7.0. Merging would be one step longer (for another year) in worst case scenario (bugfix or security fix) but even that would be less of a PITA if not for NEWS. (About the recent contributor gave up stuff: I think that is more of a problem when the policies/processes are not explicit and/or abused.) Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then it's another matter, and the lifetime of existing versions could be extended. That's one reason, which doesn't really require us to do anything, as we have plenty of time to realize if we want to/have to prolong the lifecycle of PHP5, and doesn't take much than updating http://php.net/supported-versions.php and bribing the RMs to cover another year with the RM stuff. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
RE: [PHP-DEV] [RFC] PHP 5.7
-Original Message- From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of Julien Pauli Sent: Tuesday, December 16, 2014 11:00 PM To: Florian Margaine Cc: Rowan Collins; PHP Internals Subject: Re: [PHP-DEV] [RFC] PHP 5.7 - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, under release process that forbids that) What part of the release process forbids that? I don't see that anywhere in there, at least not any more than it forbids such deprecation messages in a minor (2nd digit) version. New features are the only (relevant) difference between minor and bugfix versions, and I don't think anybody considers deprecation messages as new features. They are, in practice, very minor compatibility breakages - and in that sense, technically, both bugfix (3rd digit) and minor (2nd digit) versions forbid those equally. Also note that the release process isn't exactly a flawless document that predicted all the scenarios we're facing (and are going to face) in the future. Its focus was bugfix and minor releases, and consequently, not much thought was made regarding migration issues of the sorts we're discussing today, towards a major version. If we reach the conclusion (and it's clearly an if), it's not the release process that should stop us. - Rolling out a 5.7 with *just* Warnings-of-any-kind is silly, see the topic I just replied to which is valid to me Agreed. - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new features cancels point number one What else ? Do nothing is still (IMHO) the most sensible option IMHO. We're not seeing major compatibility breakages in 7.0 (at least not at this time), to the level that upgrading through some middle version is really all that necessary. Considering the adoption levels of 5.6, 5.5 and even 5.4, we can expect that most people migrating to PHP 7 will not be doing it from one of the latest PHP 5.x versions, but older ones, rendering all of these options useless. The one option that could be relevant to these scenarios is a separate analysis tool, but it's much more difficult to pull off, and I don't think the level of breakage (as it appears right now) justifies the effort. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On 16 December 2014 at 13:18, Andrea Faulds a...@ajf.me wrote: Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a year sounds like a better solution. If others agree, I might withdraw this RFC. I disagree. 2to3 wasn't a success in the Python world — in the end, the only migration solution that worked there was code bases that could run on both Python 2 and 3 (with the help of userland compatibility libraries like six and python-future), and I believe the same will be true for PHP 5 and 7. More generally, I don't believe a standalone CLI tool can be the whole answer even if that wasn't a problem: too many of our users only ever run their code in shared Web server environments and aren't proficient enough at the command line (on whatever OS they choose) for that kind of tooling. I'm sure someone will write a 2to3 type tool, and that some people will find it useful, but I don't think it's the right answer in terms of advertising a migration path. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] PHP 5.7
-Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: Tuesday, December 16, 2014 11:53 PM To: Florian Margaine Cc: Rowan Collins; PHP Internals Subject: Re: [PHP-DEV] [RFC] PHP 5.7 please be aware the not everybody agrees on the no new features rule, but from as I can tell most people seem to agree that no new major features should be included. That's true, but the only person I see actively campaigning for new features (major or otherwise) appears to be you, Ferenc :) It's *clearly* not in the scope of the RFC that Andrea put on the table - that's consistent with the feedbacks of several different people on the list. We'd need a different or heavily amended RFC in order to allow it. For the record, I'm mostly indifferent to the current RFC (somwhat opposing it as detailed in a previous email), but will clearly oppose any RFC that suggests any sort of feature 5.7 release. Most importantly, it will delay the strategic 7.0 release, but also - slow migration down (less reasons to move upwards to 7.0 if you have some of these features in 5.x). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On 16 December 2014 at 14:00, Zeev Suraski z...@zend.com wrote: - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, under release process that forbids that) What part of the release process forbids that? None, but I'd still advocate releasing a new minor because there's plenty of anecdata suggesting that our userbase tend to consider 5.x.y and 5.x.y+z to be the same in terms of features. We used to see this confusion in ##php a lot over things like crypt() algorithm support changing over the course of 5.3: trying to explain that you don't want to use anything before 5.3.7 is actually surprisingly difficult, whereas saying 5.4 fixes this is easy. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 9:59 PM, Julien Pauli jpa...@php.net wrote: On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine flor...@margaine.com wrote: Hi list, I think having a minor PHP version for the only sake of adding E_DEPRECATED is kind of pointless to be honest. Historically, PHP (or other languages for the matter, I'm thinking of python) minor versions have brought new features. Adding notices is not a reason for a new version imho. If what we want are notices, and helping people to migrate to PHP 7, then we can create tools for this. For example, python made a tool to help with the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if my memory serves right. The point of new versions is to include new features or bug fixes for the language, static analysis can be done with external tools. The fact that we'll have to maintain one more version is also not something to be taken lightly, especially when I see examples of how things progress in php-src. (I'm thinking about the recent contributor who gave up.) Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then it's another matter, and the lifetime of existing versions could be extended. Just my $0.02. That's a perfectly valid POV I share. So I sum-up and introduce the dilema : - We should push people to PHP7 , whatever the way I don't think we can really push people to migrate, instead of that we can make the migration as painless and possible, and hope that distros and app/lib developers will pull the ecosystem with them (for example an initiative like gophp5 would not have happened if we were trying to organize and push that or devs did not thought that php5 is superior to php4, same thing here). - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, under release process that forbids that) even thought that Pierre stated this in a previous mail, but AFAIK there is no such rule(https://wiki.php.net/rfc/releaseprocess) and we have a couple of precedences, but I do agree that it would be a bad idea to add a bunch of new errors in a micro version, as there are people out there who run code in production with enabled display_errors and have E_DEPRECATED in error_reporting: https://bugs.php.net/bug.php?id=66763 - Rolling out a 5.7 with *just* Warnings-of-any-kind is silly, see the topic I just replied to which is valid to me I think that some people in this thread would still vote yes for such a version, but I think that small additions like the last couple of function addition in 5.6.x would be ok. - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new features cancels point number one I wouldn't say it cancels it, I mean I agree that not having any new feature (even the smallest one) in 5.x will have a positive effect on the number of people upgrading, but I don't think that php7 will fail because we added gmp_random_range() in 5.6.3. What else ? I think that the core difference between the people on the two sides are how they view the gains from the easier upgrading between 5.7-7.0 versus the cost of release/maintenance of another minor and how would that affect the effort put into 7.0. I think that the pros are outweighing the cons, but that's just me. I don't know how could we quantify the first one(gains from easier upgrading), but we can try to do that for the second(future cost of maintenance) and then hold a vote to see what others think. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
RE: [PHP-DEV] [RFC] PHP 5.7
-Original Message- From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf Of Adam Harvey Sent: Wednesday, December 17, 2014 12:10 AM To: Zeev Suraski Cc: PHP Internals Subject: Re: [PHP-DEV] [RFC] PHP 5.7 On 16 December 2014 at 14:00, Zeev Suraski z...@zend.com wrote: - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, under release process that forbids that) What part of the release process forbids that? None, but I'd still advocate releasing a new minor because there's plenty of anecdata suggesting that our userbase tend to consider 5.x.y and 5.x.y+z to be the same in terms of features. We used to see this confusion in ##php a lot over things like crypt() algorithm support changing over the course of 5.3: trying to explain that you don't want to use anything before 5.3.7 is actually surprisingly difficult, whereas saying 5.4 fixes this is easy. I actually agree with that. My view, though, that if we think that delivering those deprecation messages is critical, we're facing a choice between two less-than-ideal options. The 5.7 option defeats the purpose for which it's built - getting a substantial number of people to upgrade and see those messages in the first place. It'll also create an awkward and maybe even silly situation where we'd have two active versions - both with its own monthly releases, but effectively virtually identical to each other in every regard except for these messages. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On 16 December 2014 at 14:19, Zeev Suraski z...@zend.com wrote: -Original Message- From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf Of Adam Harvey Sent: Wednesday, December 17, 2014 12:10 AM To: Zeev Suraski Cc: PHP Internals Subject: Re: [PHP-DEV] [RFC] PHP 5.7 On 16 December 2014 at 14:00, Zeev Suraski z...@zend.com wrote: - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, under release process that forbids that) What part of the release process forbids that? None, but I'd still advocate releasing a new minor because there's plenty of anecdata suggesting that our userbase tend to consider 5.x.y and 5.x.y+z to be the same in terms of features. We used to see this confusion in ##php a lot over things like crypt() algorithm support changing over the course of 5.3: trying to explain that you don't want to use anything before 5.3.7 is actually surprisingly difficult, whereas saying 5.4 fixes this is easy. My view, though, that if we think that delivering those deprecation messages is critical, we're facing a choice between two less-than-ideal options. The 5.7 option defeats the purpose for which it's built - getting a substantial number of people to upgrade and see those messages in the first place. I think it's actually more likely that people will upgrade to a new minor than a later revision that includes deprecation warnings in the long run. There's a decent amount of evidence that suggests that users tend to stick to their distro packages for minors, and those tend to be early in the minor cycle (the various version links at http://w3techs.com/technologies/details/pl-php/5/all are interesting, and I've seen non-public data that indicates the same thing). It'll also create an awkward and maybe even silly situation where we'd have two active versions - both with its own monthly releases, but effectively virtually identical to each other in every regard except for these messages. For twelve months, until 5.6 enters extended support. I think that's manageable, and although it might seem silly internally, I think it's also a better result for our users in terms of managing their migration paths. Adam, who's pretty much going to bow out of the conversation for now, since he's said everything he wanted to. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
- Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new features cancels point number one What else ? Do nothing is still (IMHO) the most sensible option IMHO. We're not seeing major compatibility breakages in 7.0 (at least not at this time), to the level that upgrading through some middle version is really all that necessary. we don't have much or really big ones(yet), we have a couple of nasty ones (eg. doesn't blow up, but behaves differently, check the mails from Derick complaining about those). and there are a couple ones upcoming/likely to make it through: https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 https://wiki.php.net/rfc/remove_php4_constructors Considering the adoption levels of 5.6, 5.5 and even 5.4, we can expect that most people migrating to PHP 7 will not be doing it from one of the latest PHP 5.x versions, but older ones, rendering all of these options useless. while I hope that you are right, but I think that PHP7 will be really interesting for two kind of people: - people who are looking for performance gains, even if it makes rewriting some code (and those who can this way have a feasible alternative instead of moving to hhvm/hack). - people who wants to start a greenfield project and for some reason they already decided to do in in php (because they already invested into the technology or because php is a really good choice for their usecase) and they are able to control their infrastructure so that they can have 7.0 on it. - they really need a feature which only 7.0 has and doing it in userland would be too hard to do or unfeasible (not sure if we have something like this in 7.0). Worst case the others will probably upgrade in the same tempo as they are currently doing or the way they did with php4 vs php5. I think that the only thing which really had an impact on the adoption rates is the fact that we provided stuff what modern frameworks/apps needed and made it easier to users/distros to upgrade. I think it is important to not forget those, and sometimes I feel that we are focus too much on shipping PHP7 only with the performance gains already present or to force people to upgrade (instead making sure that we provide what they want and the easiest upgrade path possible). The one option that could be relevant to these scenarios is a separate analysis tool, but it's much more difficult to pull off, and I don't think the level of breakage (as it appears right now) justifies the effort. fortunately we already have a couple of those for some of the nasty changes like https://gist.github.com/nikic/ffd019ef78b72934c7cc for finding code which would be affected by the behavior change of https://wiki.php.net/rfc/uniform_variable_syntax I do think that while those kind of extra steps are not mandatory per se, but they help a lot when convincing people to jump the ship and upgrade. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 11:08 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: Tuesday, December 16, 2014 11:53 PM To: Florian Margaine Cc: Rowan Collins; PHP Internals Subject: Re: [PHP-DEV] [RFC] PHP 5.7 please be aware the not everybody agrees on the no new features rule, but from as I can tell most people seem to agree that no new major features should be included. That's true, but the only person I see actively campaigning for new features (major or otherwise) appears to be you, Ferenc :) I was just pointing out, that we don't have a consensus on this decision. If I'm the minority with my opinion I will accept it, I just wanted to make sure that this kind of the discussion is not wrongly summarized/misrepresented. I do remember seeing other people who liked the idea of having small self-contained features, and from the top of my head I could only name you who was on the side of the fence that there should be no new features at all, even in 5.6, and everybody should just work on 7.0. It's *clearly* not in the scope of the RFC that Andrea put on the table - that's consistent with the feedbacks of several different people on the list. We'd need a different or heavily amended RFC in order to allow it. I think that it is sometimes better to first have a discussion before trying to put out competing RFCs if you think that there are some points/aspects which you seem to not agree on. (Usually this is the point of the Under Discussion status of the RFCs). For the record, I'm mostly indifferent to the current RFC (somwhat opposing it as detailed in a previous email), but will clearly oppose any RFC that suggests any sort of feature 5.7 release. Most importantly, it will delay the strategic 7.0 release, but also - slow migration down (less reasons to move upwards to 7.0 if you have some of these features in 5.x). could you clarify one thing for me? from that sentence it seems that you aren't really against having small new features (as those are already happened/happening in 5.6.x and you did not mention that you have a problem with that) but you think that there would be more/bigger features happening if there would be an 5.7 version? do I understand you correctly? If you have problems with small improvements happening anywhere but in 7.0, I think we should have a vote on that, because we don't really have a clean rule to prevent that from happening (or you can convince the RMs to veto every feature on the current 5.x branches). if you have problem with 5.7 growing in complexity/number of features I think that wouldn't really be a problem, as for one we would have a more formal process for approving the features what is currently happening (people asking the RMs if they think this or that is okay and in which branch should it go), plus I don't think that many people would really want to implement a complex feature twice (once against 5.7 and once against 7.0) which will be available in both versions around the same time (maybe a couple of months sooner in 5.7). Personally I don't expect more development going into 5.6+5.7 than what is currently happening in 5.6. I think this PR/mail is a good example how would having a clear target for small improvements help: https://www.mail-archive.com/internals@lists.php.net/msg71998.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] PHP 5.7
On Dec 17, 2014 4:19 AM, Andrea Faulds a...@ajf.me wrote: Hey Florian, On 16 Dec 2014, at 19:55, Florian Margaine flor...@margaine.com wrote: Hi list, I think having a minor PHP version for the only sake of adding E_DEPRECATED is kind of pointless to be honest. Historically, PHP (or other languages for the matter, I'm thinking of python) minor versions have brought new features. Adding notices is not a reason for a new version imho. If what we want are notices, and helping people to migrate to PHP 7, then we can create tools for this. For example, python made a tool to help with the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if my memory serves right. The point of new versions is to include new features or bug fixes for the language, static analysis can be done with external tools. The fact that we'll have to maintain one more version is also not something to be taken lightly, especially when I see examples of how things progress in php-src. (I'm thinking about the recent contributor who gave up.) Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then it's another matter, and the lifetime of existing versions could be extended. Just my $0.02. Cheers, Florian Margaine Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a year sounds like a better solution. If others agree, I might withdraw this RFC. Thanks! Please do not. It can be updated but discarding a rfc every time you see a slight opposition is not good. Also an extension won't have the same impact and spread than a new php release.
Re: [PHP-DEV] [RFC] PHP 5.7
On Wed, Dec 17, 2014 at 10:45 AM, Andrea Faulds a...@ajf.me wrote: Hi Pierre, On 16 Dec 2014, at 23:42, Pierre Joye pierre@gmail.com wrote: On Dec 17, 2014 4:19 AM, Andrea Faulds a...@ajf.me wrote: Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a year sounds like a better solution. If others agree, I might withdraw this RFC. Thanks! Please do not. It can be updated but discarding a rfc every time you see a slight opposition is not good. Also an extension won't have the same impact and spread than a new php release. I’m not considering dropping the RFC because of opposition. Rather, I think that suggestion is actually better than having a 5.7 release. Pretty much the same result, isn't it? There are many voices in favor of 5.7, for very good reasons (see the distros one for the most important). An extension will be useless, no impact, defeat the main goal of having a 5.7. And an extension will require much more work than having 5.7, given that the amount of work is the main argument against 5.7, I find it disturbing. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] PHP 5.7
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hi Adam, On 16 Dec 2014, at 00:15, Adam Harvey ahar...@php.net wrote: On 15 December 2014 at 16:09, Andrea Faulds a...@ajf.me wrote: 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. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Mon, Dec 15, 2014 at 4:20 PM, Andrea Faulds a...@ajf.me wrote: Hi Adam, On 16 Dec 2014, at 00:15, Adam Harvey ahar...@php.net wrote: On 15 December 2014 at 16:09, Andrea Faulds a...@ajf.me wrote: 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. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +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
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hi Xinchen, On 16 Dec 2014, at 04:07, Xinchen Hui larue...@php.net wrote: On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: 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…. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
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.. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hi everyone, On 16 Dec 2014, at 00:15, Adam Harvey ahar...@php.net wrote: On 15 December 2014 at 16:09, Andrea Faulds a...@ajf.me wrote: 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. On 16 Dec 2014, at 01:19, Kris Craig kris.cr...@gmail.com wrote: +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. On 16 Dec 2014, at 05:51, Andrea Faulds a...@ajf.me wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On 16/12/2014 05:07, Xinchen Hui wrote: On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: 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.. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hi Matteo, On 16 Dec 2014, at 07:52, Matteo Beccati p...@beccati.com wrote: On 16/12/2014 05:07, Xinchen Hui wrote: On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: 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.. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 8:52 AM, Matteo Beccati p...@beccati.com wrote: On 16/12/2014 05:07, Xinchen Hui wrote: On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: 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.. 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
