Good evening,
Normally I just reply to [VOTE] threads when a vote ends, but Pierre said making a separate thread in future would be a good idea, and I see no real harm in it. This way it’ll catch the attention of people who don’t read all replies to a thread.
I’m actually closing this vote a little late, it should’ve closed a bit before 3pm GMT, but I assumed the vote had been opened in the evening. No harm done.
The vote on the PHP 5.7 RFC has closed. By 19 votes to 14, the RFC has been rejected. This means we won’t be having a PHP 5.7 release, unless another RFC is made and voted on.
The RFC and vote totals are here: https://wiki.php.net/rfc/php57
Thank you everyone for your time!
Andrea Faulds
http://ajf.me/
Good evening,
Normally I just reply to [VOTE] threads when a vote ends, but Pierre said making a separate thread in future would be a good idea, and I see no real harm in it. This way it’ll catch the attention of people who don’t read all replies to a thread.
I’m actually closing this vote a little late, it should’ve closed a bit before 3pm GMT, but I assumed the vote had been opened in the evening. No harm done.
The vote on the PHP 5.7 RFC has closed. By 19 votes to 14, the RFC has been rejected. This means we won’t be having a PHP 5.7 release, unless another RFC is made and voted on.
The RFC and vote totals are here: https://wiki.php.net/rfc/php57
Thank you everyone for your time!
too bad.
And please, anyone, do not come up with "let add some warning in
5.6.x", please. do. not. We want to make migration and forward
compatible code harder to see? let assume it and at least follow this
part of the release process RFC.
--
Pierre
@pierrejoye | http://www.libgd.org
Hi,
The vote on the PHP 5.7 RFC has closed. By 19 votes to 14, the RFC
has been rejected. This means we won’t be having a PHP 5.7 release,
unless another RFC is made and voted on.
I am still convinced that it was premature to open the voting on the 5.7
RFC.
The current PHP7 doesn't have huge BC breaks as far as I can tell, and
that's why I (and possibly others) have voted "no".
As of now, PHP 5.7 would have been for me just one more PHP version to
take into account for CI/QA/testing. A burden if you will.
This might however change in the future, depending on the results
of forthcoming RFCs. If some "evil" BC breaks get to PHP7, then having
5.7 might have been handy, but we've just ruled out this possibility.
Still, I just didn't feel it was right to vote "yes" based on such
uncertainty.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi!
The current PHP7 doesn't have huge BC breaks as far as I can tell, and
that's why I (and possibly others) have voted "no".
For the record, it's exactly why I voted no too. If we end up having
ones (e.g. a huge BC break looming in the strict types RFC) that may change.
of forthcoming RFCs. If some "evil" BC breaks get to PHP7, then having
5.7 might have been handy, but we've just ruled out this possibility.
We didn't actually - we could resurrect that RFC and have another vote
when the circumstances change.
Stas Malyshev
smalyshev@gmail.com
of forthcoming RFCs. If some "evil" BC breaks get to PHP7, then having
5.7 might have been handy, but we've just ruled out this possibility.We didn't actually - we could resurrect that RFC and have another vote
when the circumstances change.
It's rather embarrassing, but I just didn't think about it ;)
Thanks for the clarification.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi Andrea,
I’m actually closing this vote a little late, it should’ve closed a bit
before 3pm GMT, but I assumed the vote had been opened in the evening. No
harm done.The vote on the PHP 5.7 RFC has closed. By 19 votes to 14, the RFC has
been rejected. This means we won’t be having a PHP 5.7 release, unless
another RFC is made and voted on.The RFC and vote totals are here: https://wiki.php.net/rfc/php57
I thought there will be 5.7 and didn't pay much attention on this. Slow
transition is better than too fast. I can understand the argument that
PHP 7 does not break much, but I'm in favor of having 5.7 still.
As Stas pointed out, let's have a vote again if PHP 7 includes more
destructive
changes.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
I thought there will be 5.7 and didn't pay much attention on this. Slow
transition is better than too fast.
Slow transition is good, but, sometimes, it is too slow; I don't know if you remember how much time was necessary to stop backporting PHP5 patches to PHP4 ? The official reason was to make the migration slower and easier for our user base. Unfortunately, this was understood by several PHP software companies (no name here) as a signal that migrating their software to PHP5 was not so urgent and that they could sleep until PHP5 was stabilized. The only people who were actively working were PHP core developers, who had to stabilize PHP5 AND backport features to PHP4, wasting a lot of time and energy. Fortunately, most people backporting the patches were working for these companies :) The mistake we did, IMO, was to consider that new features were attractive enough to cause developers to speed up their migration. PHP5 was nice but OO already existed in PHP4 and most new features continued to be backported : no reason to speed up anything !
In this respect, I don't see much in PHP7 that will motivate our users to speed up their migration. Most features I see are uninteresting for at least 90% of our user base and even performance gains are hard to sell, let alone phpng, AST, or deprecated features :). The only feature I see that could be interesting from an end user point of view is named parameters but I don't know if it is still active. Another subject that could be very attractive is what I named 'pseudo-methods' (Nikita used the same term in his article). This is a way to provide an OO-like syntax applied to scalars, without loosing the benefits of loose typing, but solving the two main problems with functions : argument order and nested calls readability. Maybe I'll propose this feature but I am afraid of the reactions it could generate, as the trend seems to build a complex full-featured OO system and extend to scalars. I am totally opposed to this approach but it seems that's what most core dev want. My solution is much simpler, probably too simple for people hypnotized by java. The same for 'friend classes'. I won't even write the RFC as it seems it does not interest anyone. Strange because, googling around, it is visible that a lot of users are expecting this feature...
Well, the feature list for PHP7 is not closed yet. I hope new attractive features will be added soon because, otherwise, it will be very hard to sell. And we need attractive features in the first release, not 7.1 or 7.2, which will never have the same exposure.
Regards
François
Well, the feature list for PHP7 is not closed yet. I hope new attractive
features will be added soon because, otherwise, it will be very hard to
sell. And we need attractive features in the first release, not 7.1 or 7.2,
which will never have the same exposure.
I cannot say it in a better way. Full ack.
Hi all,
Well, the feature list for PHP7 is not closed yet. I hope new attractive
features will be added soon because, otherwise, it will be very hard to
sell. And we need attractive features in the first release, not 7.1 or 7.2,
which will never have the same exposure.I cannot say it in a better way. Full ack.
I agree this, too.
As internet became a hunting place for professional crackers (criminals), I
really
would like to make PHP secure by default. It's getting better, but it is
not enough.
One example is htmlspecialchars(). HTML 5 allows attributes quoted by " '
and w/o
quotes. It does not produce safe string by default. Another example is
"embed script
by default/always". It's a needless risk (i.e. Local/Remote Script
Inclusion), IMHO.
Yet another example is lack of JavaScript string escape function. I also
would like
to see OpenSSL/LibreSSL extension enabled by default.
Security improvement may attract many users hopefully.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
Well, the feature list for PHP7 is not closed yet. I hope new attractive features will be added soon because, otherwise, it will
be very hard to sell. And we need attractive features in the first release, not 7.1 or 7.2, which will never have the same
exposure.
I cannot say it in a better way. Full ack.
I agree this, too.
As internet became a hunting place for professional crackers (criminals), I really
would like to make PHP secure by default. It's getting better, but it is not enough.
One example ishtmlspecialchars(). HTML 5 allows attributes quoted by " ' and w/o
quotes. It does not produce safe string by default. Another example is "embed script
by default/always". It's a needless risk (i.e. Local/Remote Script Inclusion), IMHO.
Yet another example is lack of JavaScript string escape function. I also would like
to see OpenSSL/LibreSSL extension enabled by default.
Security improvement may attract many users hopefully.
Great ideas !
IMO, that's the kind of features we need: more or less hard to implement and easy to explain and get people interesting in. You're right: if we provide enough security-related fixes and enhancements, this can be a perfect focus when communicating about PHP7. It can look like demagogy but it's only basic communication rules. People (including all of us) need to make a first opinion after reading less than 10 words (and it becomes shorter every day :). If PHP7 is announced as 'a new version focusing on security', it is a reason to read further for a lot of people. If we give them a long list of opaque features they don't understand, they give up after reading 2 lines ! The REALLY most important features are probably phpng or AST, but our only goal is to have users migrate to the new version.
Unfortunately, that's frustrating for people implementing hidden, complex features, like AST or phpng, which won't have the recognition they would deserve. But I don't know any way to fix this. IMO, there's no way to have the mass of PHP developers understand what they owe them. It doesn't mean this work is not important but, when you start working on such low-level features, you must know that recognition will come from your peers, rarely from the public. I even consider that an important benefit of PHP conferences is to provide a way for these people to get the recognition they deserve, which allows to keep them motivated.
Please go on with a global security-related RFC and a thread where all of us will bring forgotten feature requests. IMO, no need to be extremely creative in searching issues to solve. We have tons of never-addressed security-related enhancement requests in the bug tracker. Sites like PHP sadness are a source too. Many others like StackOverflow also contain a lot of ideas and complains in this domain.
Regards
François
Regards,