rfc:php6

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
rfc:php6 [2014/07/22 14:09]
zeev When someone writes half the RFC, you consider him an author, not a contributor :)
rfc:php6 [2014/07/23 13:53]
nikic lucky numbers are no longer mentioned
Line 1: Line 1:
 ====== PHP RFC: Name of Next Release of PHP ====== ====== PHP RFC: Name of Next Release of PHP ======
   * Version: 2.0   * Version: 2.0
-  * Date: 2014-07-05 (latest 2014-07-20+  * Date: 2014-07-05 (latest 2014-07-22
-  * Author: Andrea Faulds <ajf@ajf.me>, Zeev Suraski <zeev@php.net> +  * Authors: Andrea Faulds <ajf@ajf.me>, Zeev Suraski <zeev@php.net> 
-  * Status: Under Discussion+  * Status: In Voting
   * First Published at: http://wiki.php.net/rfc/php6   * First Published at: http://wiki.php.net/rfc/php6
  
Line 41: Line 41:
   * Unlike the 'trivia question' of 'why did we skip into 7?', reusing version 6 is likely to call **real** confusion in people's minds, with ample information on two completely different versions with entirely different feature sets that have the exact same name.   * Unlike the 'trivia question' of 'why did we skip into 7?', reusing version 6 is likely to call **real** confusion in people's minds, with ample information on two completely different versions with entirely different feature sets that have the exact same name.
   * Skipping versions isn't unprecedented or uncommon in both open source projects and commercial products.  MariaDB, jumped all the way up to version 10.0 to avoid confusion, Netscape Communicator skipped version 5.0 directly into 6.0, and Symantec skipped version 13.  Each and every one of those had different reasons for the skipping, but the common denominator is that skipping versions is hardly a big deal.   * Skipping versions isn't unprecedented or uncommon in both open source projects and commercial products.  MariaDB, jumped all the way up to version 10.0 to avoid confusion, Netscape Communicator skipped version 5.0 directly into 6.0, and Symantec skipped version 13.  Each and every one of those had different reasons for the skipping, but the common denominator is that skipping versions is hardly a big deal.
 +  * Version 6 is generally associated with failure in the world of dynamic languages.  PHP 6 was a failure;  Perl 6 was a failure. It's actually associated with failure also outside the dynamic language world - MySQL 6 also existed but never released.  The perception of version 6 as a failure - not as a superstition but as a real world fact (similar to the association of the word 'Vista' with failure) - will reflect badly on this PHP version.
 +  * The case for 6 is mostly a rebuttal of some of the points above, but without providing a strong case for why we *shouldn't* skip version 6.  If we go with PHP 7, the worst case scenario is that we needlessly skipped a version.  We'd still have an infinite supply of major versions at our disposal for future use.  If, however, we pick 6 instead of 7 - the worst case scenario is widespread confusion in our community and potential negative perception about this version.
  
-To summarizeversion 6 is already taken by highly publicized project that is in the minds of a very large chunk of PHP developers, internals and general PHP community alike. +As a special non serious bonusis perceived as lucky number in both the Western world and Chinese culture A little bit of luck never hurt anybody.  [[http://en.wikipedia.org/wiki/Numbers_in_Chinese_culture]] (no, we're not truly seeing it as a real advantage - the case for 7 is very strong without it).
-The proposal to reuse it for something completely different will gain us absolutely nothing, and will in turn cause much confusion.+
  
-Other than having good reasons to skip and no reasons not to, there are also some minor reasons of why PHP 7 is actually nicer choice:  +==== Summary ==== 
 + 
 +Version is already taken by a highly publicized project that is in the minds of a very large chunk of PHP developers, internals and general PHP community alike. 
 + 
 +We risk nothing by calling it PHP 7.  We risk confusion and negative perception if we insist on reusing 6 for a completely different project. 
 + 
 +Taking a risk that stands to yield absolutely no reward is not good strategy.
  
-  * Version 6 is generally associated with failure in the world of dynamic languages.  PHP 6 was a failure;  Perl 6 was a failure. It's actually associated with failure also outside the dynamic language world - MySQL 6 also existed but never released. 
-  * 7 is perceived as a lucky number in both the Western world and Chinese culture.  A little bit of luck never hurt anybody.  [[http://en.wikipedia.org/wiki/Numbers_in_Chinese_culture]] (no, we're not truly seeing it as a big advantage). 
  
 ===== The Case for PHP 6 ===== ===== The Case for PHP 6 =====
Line 58: Line 63:
   * While many participants on the internals mailing list were involved in the original PHP 6 effort and as such are acutely aware of its existence, the larger PHP community is not. While discussing this RFC with various developers, many did not really understand why this was even a question, because they were no more than vaguely aware that there was something like PHP 6 in the past. As such wrong expectations due to confusion about the version number should be minimal.   * While many participants on the internals mailing list were involved in the original PHP 6 effort and as such are acutely aware of its existence, the larger PHP community is not. While discussing this RFC with various developers, many did not really understand why this was even a question, because they were no more than vaguely aware that there was something like PHP 6 in the past. As such wrong expectations due to confusion about the version number should be minimal.
   * While there has certainly been precedent for missing version numbers, the examples given in the previous section involve larger changes to versioning. When going from version 1.4 to 5.0 it's a clear change in the versioning scheme and not just a skipped version. The existing precedent suggests going to PHP 2016 or something equally distinct, rather than skipping a version. (No, this is not a serious suggestion.)   * While there has certainly been precedent for missing version numbers, the examples given in the previous section involve larger changes to versioning. When going from version 1.4 to 5.0 it's a clear change in the versioning scheme and not just a skipped version. The existing precedent suggests going to PHP 2016 or something equally distinct, rather than skipping a version. (No, this is not a serious suggestion.)
-  * Choosing a language version based on "lucky numbers" or other superstition seems questionable. 
- 
  
 ===== Vote ===== ===== Vote =====
Line 66: Line 69:
  
 Voting started 2014-07-20 but was cancelled. Voting started 2014-07-20 but was cancelled.
 +
 +Voting restarted 2014-07-23 afresh and ends 2014-07-30.
 +
 +<doodle title="Shall the name of PHP NEXT be PHP 6, or PHP 7?" auth="user" voteType="single" closed="false">
 +   * PHP 6
 +   * PHP 7
 +</doodle>
  
 ===== References ===== ===== References =====
rfc/php6.txt · Last modified: 2017/09/22 13:28 (external edit)