| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| rfc:php6 [2014/07/21 09:32] – add historical context nikic | rfc:php6 [2017/09/22 13:28] (current) – external edit 127.0.0.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> | * Authors: Andrea Faulds <ajf@ajf.me>, Zeev Suraski <zeev@php.net> |
| * Contributors: Zeev Suraski <zeev@php.net> (Case for PHP 7) | * Status: Accepted (Name is PHP 7) |
| * Status: Under Discussion | |
| * First Published at: http://wiki.php.net/rfc/php6 | * First Published at: http://wiki.php.net/rfc/php6 |
| |
| * While it's true that the other PHP 6 never reached General Availability, it was still a very widely published and well-known project conducted by php.net that will share absolutely nothing with the version that is under discussion now. Anybody who knew what PHP 6 is (and there are many) will have a strong misconception in his or her mind as to the contents and features of this new upcoming version (essentially, that it's all about Unicode). | * While it's true that the other PHP 6 never reached General Availability, it was still a very widely published and well-known project conducted by php.net that will share absolutely nothing with the version that is under discussion now. Anybody who knew what PHP 6 is (and there are many) will have a strong misconception in his or her mind as to the contents and features of this new upcoming version (essentially, that it's all about Unicode). |
| * PHP 6, the original PHP 6, has been discussed in detail in many PHP conferences. It was taught to users as a done-deal, including detailed explanations about features and behavior (by php.net developers, not 'evil' book authors). | * PHP 6, the original PHP 6, has been discussed in detail in many PHP conferences. It was taught to users as a done-deal, including detailed explanations about features and behavior (by php.net developers, not 'evil' book authors). |
| | * PHP 6 was widely known not only within the Internals community, but around the PHP community at large. It was a high profile project that many - if not most - PHP community members knew about. |
| * There's lots of PHP 6 information, about the original PHP 6, that exists around the web. Books are the smallest part of the problem. | * There's lots of PHP 6 information, about the original PHP 6, that exists around the web. Books are the smallest part of the problem. |
| * 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. |
| | * 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 summarize, PHP 6 is a living memory in the minds of many developers - internals and PHP community alike; Reusing it will cause unnecessary confusion while gaining nothing. | As a special non serious bonus, 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 real advantage - the case for 7 is very strong without it). |
| |
| Other than having good reasons to skip 6 and no reasons not to, there are also some minor reasons of why PHP 7 is actually a nicer choice: | ==== Summary ==== |
| |
| * 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. Java jumped from version 1.4 to version 5.0. | Version 6 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. |
| * 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]] | |
| * 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 Case for PHP 6 ===== | 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. |
| |
| The case for PHP 6 mostly comes down to why we shouldn't go for another name, rather than a case for it specifically. PHP 6 is the most obvious name choice as it follows the existing numbering scheme. Do we really need to break from it? | Taking a risk that stands to yield absolutely no reward is not a good strategy. |
| |
| The main argument against this is that there was previously a project, which was abandoned in 2010, also called PHP 6. There have been many discussions about it in the past and some books and articles dealing with it exist, and this could cause confusion. Essentially, we would be naming a new version with the same name as a previous, but never properly released and abandoned version. A little looking at Amazon reveals that some of these "PHP 6" books do not actually cover PHP 6 at all, and many of the books are of poor quality. Furthermore, I expect that we could easily clarify if necessary that this PHP 6 was not the subject of those books, and I think that much would be obvious to users given that the new PHP 6 would be released in 2015 at the very earliest, more than 5 years after all existing "PHP 6" books would have been published. | |
| |
| In past discussions, "PHP 7" has also been suggested as a name, to make it clear that this new version of PHP is unrelated to the old "PHP 6". However, it has been argued that it would not reduce confusion (people would wonder why the version 6 was skipped), and that people who would be likely to fall for "PHP 6" books might look for PHP 7 books, be unable to find them, and end up buying the old "PHP 6" books as they would seem, by the version number, to be the most up-to-date. While it could be argued that "PHP 7" is breaking with the numbering scheme by "skipping" a version, it could also be argued that it isn't, as PHP 6, even if it was never properly released, was a real version in development. | ===== The Case for PHP 6 ===== |
| |
| Another point that has been made is that due to online reviews, it would quickly become clear that these old "PHP 6" books do not cover the new PHP 6; people would likely try them, find the code in the book did not work, and rate the book "1 star", deterring other customers. Furthermore, the PHP community would likely try to dissuade people from buying these old "PHP 6" books. Some also question how many of the old "PHP 6" books are still in print, for that matter. | * According to our current release process and semantic versioning, the next major version after PHP 5 should be PHP 6. Unless there are very strong reasons to the contrary, we should not abandon our current version numbering scheme. |
| | * While there exists a number of resources about the previous attempt at a PHP 6 release, these will be quickly displaced once PHP 6 is actually released. This applies both to blog posts, which will be (and partially already are) displaced by newer content, and books, which will receive negative reviews because they do not actually cover the version of PHP they claim to cover. |
| | * By now there are also many resources which refer to the next major version as "PHP 6", without having any relation to the abandoned previous attempt. This includes anything from blog posts and discussions about features for the upcoming version, to RFCs and design documents in this wiki. Calling the next major version "PHP 7" instead will cause confusion in this direction. |
| | * In OTR discussions about a new major version, it is nearly always referred to as "PHP 6". Given that the current version is PHP 5, people understandably jump to the conclusion that the next one will be "PHP 6" and refer to it as such. In the minds of many devs "PHP 6" is already deeply ingrained as the name of the next major. |
| | * 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, this usually occurs in the context of larger changes to the versioning scheme. For example, when Java went from 1.4 to 5.0, it's clear that the numbering system changed. The existing precedent suggests going to PHP 2016 or something equally distinct, rather than just skipping a version. (No, this is not a serious suggestion.) |
| |
| ===== Vote ===== | ===== Vote ===== |
| |
| Voting started 2014-07-20 but was cancelled. | Voting started 2014-07-20 but was cancelled. |
| | |
| | Voting restarted 2014-07-23 afresh and ended 2014-07-30. |
| | |
| | <doodle title="Shall the name of PHP NEXT be PHP 6, or PHP 7?" auth="user" voteType="single" closed="true"> |
| | * PHP 6 |
| | * PHP 7 |
| | </doodle> |
| |
| ===== References ===== | ===== References ===== |