Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75297
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <650742796f119ed972a688a58e02242b@mail.gmail.com>
References: <61EEC54E-7B8D-433E-A391-75F8D6A41E79@ajf.me>
	<650742796f119ed972a688a58e02242b@mail.gmail.com>
Date: Mon, 7 Jul 2014 13:31:06 +0200
Message-ID: <CAEZPtU7WuRQToC6MVoqz7-O2TFL3Q6vgp4ZUD6dto0pkn-4bFw@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Name of Next Release of PHP
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Sat, Jul 5, 2014 at 11:57 PM, 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.

I think it is not premature but also totally not important, but a
matter of priorities I suppose...

> 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'.

Agree here, while my oppinion is clearly for 6, which is the next
major version after 5, last time I checked. But as you said, no need
to re do the discussions.

> 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,

I seriously hope that you take 2015 as pure example here. As I see no
remote chance to be ready next year. PHPNG is a huge stack of
undocumented perf patches far from being ready, APIs &code cleanup did
not even begin, and the existing APIs are even more ugly. This is not
going to be a small task, besides other things that we may like to
have in the next major version. A 2 years development period sounds
much more realistic to me.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org