On 5 Jul 2014, at 22:57, Zeev Suraski <z...@zend.com> wrote: > While I'm not sure whether this isn't a bit premature to have this > discussion, if we were to have this discussion, the RFC should do a much > better job at summarizing the discussions we already had in the past.
That’s true. I’ve updated it with more arguments from past discussions. > First, it shouldn't be a yes/no for PHP 6, but rather, a 'PHP 6, PHP 7, or > Defer Decision' or at least 'PHP 6 / PHP 7’. I don’t want to have a vote with over two choices, I don’t think it would be fair (one option could pass without >50% voting for it), and a binary 6/7 choice is forcing people’s hand. I want it to be simple and straightforward, so that is why it is Yes or No to PHP 6. If people vote no, there could always be a different vote later, but that is not what I want to do. I am not going to change the vote options. > Secondly, contrary to what the RFC implies, the reasons against using > version 6 went far beyond books - and covered much more important things > (honestly I never quite understood the preoccupation with this books > angle, I don't think anybody at all cares about it). If we decide to do > the discussion now, the RFC should cover them (they were discussed in a > thread named "About PHP6 ..." > > Third, numerous people (myself included) actively proposed we skip version > 6 and go with version 7; Dismissing that with "I don't think the > alternative naming options are really much better" doesn't seem to belong > in an RFC. The merits of this option - which were really more about the > drawbacks of calling it '6' and the lack of drawbacks of calling it '7' > should be properly described in the RFC. I’ve covered the PHP 7 issue more now. > Of course, you don't have to buy into that reasoning, but let's not tuck > the discussion away under the carpet. If we were to have this discussion > now, let's make the best cases we can for both options on the table, > instead of focusing on just one and dismissing the opposition as something > about books. Sure. > Another couple of cents - both because of what I said here but also > unrelated, I think /rfc/php6 is a bad name for this RFC (both because > there's more than one option, but also because this is too generic for > something as wide as the next version of PHP). Perhaps /rfc/php2015 is a > better choice, or at least /rfc/php.next.name Right, the URL isn’t entirely ideal, but it’s not really important. I don’t think it’s possible to change it, and this is at least memorable. Really, RFC URLs are pretty meaningless. We’ve had URLs before with spelling errors in them. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
