Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75265
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
In-Reply-To: <650742796f119ed972a688a58e02242b@mail.gmail.com>
Date: Sat, 5 Jul 2014 23:20:25 +0100
Cc: PHP <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <CA0E4289-C03E-48E0-ACA3-FB9CD9632FBD@ajf.me>
References: <61EEC54E-7B8D-433E-A391-75F8D6A41E79@ajf.me> <650742796f119ed972a688a58e02242b@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] Name of Next Release of PHP
From: ajf@ajf.me (Andrea Faulds)


On 5 Jul 2014, at 22:57, Zeev Suraski <zeev@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=92s true. I=92ve 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=92.

I don=92t want to have a vote with over two choices, I don=92t think it =
would be fair (one option could pass without >50% voting for it), and a =
binary 6/7 choice is forcing people=92s 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 ..."
>=20
> 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=92ve 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=92t entirely ideal, but it=92s not really important. =
I don=92t think it=92s possible to change it, and this is at least =
memorable. Really, RFC URLs are pretty meaningless. We=92ve had URLs =
before with spelling errors in them.

Thanks.
--
Andrea Faulds
http://ajf.me/