[VOTE][RFC] PHP 5.7 View as Markdown

Hey Ferenc,

I'm not entirely sure that it is a good idea to go through the voting, as in a previous mail you wrote that you don't support the idea anymore and you plan withdrawing it:
internals@lists.php.net/msg72085.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg72085.html
internals@lists.php.net/msg72098.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg72098.html

I did say that, but I never actually did it because I wasn’t completely convinced by that idea either.

I was planning to create a RFC for 5.7 with some differences to yours (mostly about having minor self-contained features should target 5.7 and making a stronger point for why 5.7 would be useful), but given the current situation I have no favorable outcome, I either vote for an 5.7 which I disagree with in small details (and which will most likely fail the vote because the rfc doesn't really make a strong point for itself nor did you incorporate anything to the rfc which was discussed in the thread) or vote against it when I really think that having an 5.7 would be really useful.

I did incorporate things into the RFC that were discussed in the thread, the timetable changes in particular.

If you want to work on the RFC, I’d be happy to cancel the vote for now so you can make changes.

I’m not sure about allowing small features, but that is up to you. If we’re talking about the kind of things that go into normal minor releases, then there’s a risk of people not bothering to upgrade to PHP 7. Then again, we need to actually encourage people to upgrade to 5.7 first. Development of new features for 5.7 would be difficult because everything you do must essentially be rewritten for 7.0 given the huge internals changes. This also creates unfortunate QA issues, since your 7.0 and 5.7 implementations must have exactly matching behaviour. But there might be a case for small features like we have sometimes in micros, e.g. adding parameters to functions. It’s your call.

Thanks.

Andrea Faulds
http://ajf.me/

I still haven't achieved a proper understanding of what 5.7 would
actually include (so far the only real BC thing mentioned that it can
warn about is the switch thing, and IMHO making the new minor just
because of that makes little sense, of course I'm not counting
non-accepted RFCs since otherwise there's like 40 of them), so I intend
to vote no, but if somebody really sees something substantial that I
missed, please point me out, as I am not opposed to the idea of 5.7 just
don't see any practical content for it for now.

Would the unassociation or deprecation-for-unassociation of the ternary
'?' (discussed in another thread [1]) be appropriate for the 5.7? Kris
Craig mentioned he would write up an RFC for this when he has a chance.

[1]
http://grokbase.com/t/php/php-internals/14cdp789nk/fix-incorrect-ternary-associativity-for-7-0

thanks,
Leon

Hey Stas,

I still haven't achieved a proper understanding of what 5.7 would
actually include (so far the only real BC thing mentioned that it can
warn about is the switch thing, and IMHO making the new minor just
because of that makes little sense, of course I'm not counting
non-accepted RFCs since otherwise there's like 40 of them), so I intend
to vote no, but if somebody really sees something substantial that I
missed, please point me out, as I am not opposed to the idea of 5.7 just
don't see any practical content for it for now.

Basically, it would include everything that the latest 5.6.x release had at the time it was finalised, plus deprecation notices and new reserved words (if any). That would be it. If that doesn’t seem worth it to you, I won’t stop you voting against it. :)

Thanks.

Andrea Faulds
http://ajf.me/

Hi!

I’m going to put the PHP 5.7 RFC to a vote, since it’d been 2 weeks.
I’m not entirely certain myself whether it’s a good idea, but I’d
like it for us to vote on it so we can settle the matter. If people
vote against 5.7, a new RFC proposing an alternative could always be
made by someone.

I still haven't achieved a proper understanding of what 5.7 would
actually include (so far the only real BC thing mentioned that it can
warn about is the switch thing, and IMHO making the new minor just
because of that makes little sense, of course I'm not counting
non-accepted RFCs since otherwise there's like 40 of them), so I intend
to vote no, but if somebody really sees something substantial that I
missed, please point me out, as I am not opposed to the idea of 5.7 just
don't see any practical content for it for now.

My take is that anything that takes away efforts from getting PHP 7 to market faster is a distraction.
PHP.net needs to continue to show leadership in evolving the runtime. We have a pretty great jewel in our hands. Some very good RFCs that are going to make it in. Postponing PHP 7 (which this would as we have a finite amount of resources on this list) would not be good for our users.

Andi

P.S. - Not interested in debating it. Definitely accept folks can have other views. Just wanted to state my opinion clearly :)

The voting widget and RFC can be found here: https://wiki.php.net/rfc/php57

Hi,

We've discussed this RFC with other members of AFUP and while opinions
have been expressed for both "yes" and "no", it seems we are at about
2/3 of "yes" -- which means we would be +1.

Note, though, we are mostly a community of users (which means we
generally have a point of view of "users") -- and there aren't many PHP
contributors amongst us.

Trying to summarize what we have said, on the +1 side :

• PHP 5.x would be maintained (especially, it would receive security
  fixes) for one additional year, which would be a good thing for those
  who will not update to PHP 7 soon (and there are some -- still, not sure
  they would update to PHP 5.7 either)
• Notices / deprecation warnings could help making the migration to
  PHP 7 easier (once you've migrated to the last 5.x minor version and
  fixed a few things, you'll know migrating to the next major should not
  be too hard)

And, on the -1 side :

• Even if there is no PHP 5.7, we already have something like 2 years
  left before PHP 5.6 stops getting security fixes -- and, taking a look
  at current versions usage, if one doesn't upgrade in 2 years, they
  probably won't upgrade in 3 years either.
• Things that will break for PHP 7 will be indicated by the migration
  guide (and there are some automatic helper tools for some)
• There are not that many PHP contributors -- which means having PHP
  5.7 and PHP 7 more or less in parallel might slow PHP 7 down (not only
  for the initial release, but also for maintenance and evolutions later).

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/