Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75267
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: <d551b5cd173fde7b3192f9fb740fc4e5@mail.gmail.com>
Date: Sun, 6 Jul 2014 00:18:56 +0100
Cc: PHP <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E0A23B54-C1E5-446A-AB97-3A90A336EC0D@ajf.me>
References: <61EEC54E-7B8D-433E-A391-75F8D6A41E79@ajf.me> <650742796f119ed972a688a58e02242b@mail.gmail.com> <CA0E4289-C03E-48E0-ACA3-FB9CD9632FBD@ajf.me> <d551b5cd173fde7b3192f9fb740fc4e5@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 6 Jul 2014, at 00:05, Zeev Suraski <zeev@zend.com> wrote:

> I think there's some confusion here.
>=20
> If the next version of PHP is going to be a major one (which is =
clearly
> defined in https://wiki.php.net/rfc/releaseprocess), then I believe =
the
> only two options that were ever raised are PHP 6 and PHP 7.  If you're
> aware of other proposals that were made then please state them, =
otherwise,
> I think it's a very clear decision between 6 and 7 - and putting this =
as a
> 'yes/no' for 6 gives it undue advantage.

Well, if we have the current yes/no to PHP 6 vote, then if it passes, we =
get PHP 6. If it doesn=92t pass, we=92re back where we were before.

If we go for PHP 6/PHP 7 vote, then the result is unclear. Would one =
option be the default? Would it be PHP 7 if it=92s not PHP 6? Would it =
be PHP 6 if it=92s not PHP 7? In which case, what=92s the point in a =
majority? We could hold a 50%+1 vote, but such a vote would be =
contentious and would be a popularity contest, not requiring consensus. =
If we don=92t have a default, and either 6 has to get 2/3 or 7 has to =
get 2/3, then we should have an Other option, or a Continue Discussion =
option, or both. This is all way too complicated for me and I don=92t =
want the vote to be contentious or confusing.

Hence, it is a Yes/No vote to PHP 6. If it fails, we are back to where =
we were before. If it passes, the name is PHP 6. It could not be more =
straightforward, and the result cannot be misinterpreted. It requires a =
2/3 majority to pass, so it would require consensus. Again, this is my =
position and I am sticking to it. I see no good reason to complicate =
matters.

>> I've covered the PHP 7 issue more now.
>=20
> Not really, not in a meaningful way.  You haven't covered the real
> drawbacks of calling it PHP 6 (it's still this books thing which =
nobody
> cares about, and perhaps even incites people to support 6 just to =
spite
> these 'evil book authors'), and you haven't covered the advantages or
> disadvantages of calling it 7 - beyond a very weak and very biased
> dismissal.  I'm intentionally not going into those here, because I =
don't
> want to (re)start the discussion right here and now.  A lot has been =
said
> already about this and the RFC should reflect it, or not move ahead.

I=92m willing to take suggestions, if that could improve it.

> Andrea - this updated RFC is the very definition of tucking the =
discussion
> under the carpet and trying to run ahead to force a 6 decision without
> doing the discussion that already took place any justice.
>=20
> The only way to really make the case for both options is for someone =
who
> believes in each option to make the case;  And to make this RFC about =
a
> decision between these two.

Which options? 6 and 7? This isn=92t a 6 vs 7 RFC. This is a 6 or not =
RFC.

Sure, I can=92t make a great case against 6, unfortunately. I am willing =
to accept suggestions here.

> However, I have to say I wish that instead of (IMHO) wasting energy on
> such a discussion at this point, we'd focus on the actual content of
> php.next.  People sharing phpng benchmarks and testing it with their =
apps
> would be a whole lot more productive use of our time.

The entire point of this RFC is to get the discussion over with sooner =
rather than later, and hopefully come to a decision quickly so we don=92t =
need to discuss it again.

Also, I disagree that holding a vote to settle the name matter once and =
for all is a waste of energy. It should, hopefully, mean less energy =
wasted than otherwise in future.
--
Andrea Faulds
http://ajf.me/