Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.172 as permitted sender)
References: <61EEC54E-7B8D-433E-A391-75F8D6A41E79@ajf.me> <1E40C2BC-3C86-4D20-9C34-C8E0B6BFF925@ajf.me>
 <53B953A8.7070904@lsces.co.uk> <A81D09BC-A2FF-465E-9D6B-D84CC73F24DE@ajf.me>
 <53B97D60.7010503@lsces.co.uk> <F2D21929-13CE-4660-8E67-11BE9A0A53A1@ajf.me>
In-Reply-To: <F2D21929-13CE-4660-8E67-11BE9A0A53A1@ajf.me>
Mime-Version: 1.0 (1.0)
Date: Sun, 6 Jul 2014 13:35:50 -0400
Message-ID: <150983875208545046@unknownmsgid>
To: Andrea Faulds <ajf@ajf.me>
Cc: Lester Caine <lester@lsces.co.uk>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Name of Next Release of PHP
From: zeev@zend.com (Zeev Suraski)

When you have infinity at your disposal,  skipping 6 and taking the
next free number - 7 - makes a whole lot more sense than trying to
rewrite the archives of history (renaming 6 to Old 6).

Similarly, while there are fairly good reasons on why we shouldn't use
6, there aren't any for the next-in-line number - 7 - so the whole
question on maybe we should pick 14, Luxonda or anything else that
implies we change our versioning scheme.  We're not - we're just not
using a version number that was already used.

Zeev

> On 6 =D7=91=D7=99=D7=95=D7=9C 2014, at 13:07, Andrea Faulds <ajf@ajf.me> =
wrote:
>
>
>>> On 6 Jul 2014, at 17:46, Lester Caine <lester@lsces.co.uk> wrote:
>>>
>>> On 06/07/14 16:08, Andrea Faulds wrote:
>>> I think it=E2=80=99s generally clear what=E2=80=99s for the new PHP 6 a=
nd what=E2=80=99s for the old; anything from after the old PHP 6 was abando=
ned must be about a new PHP 6, and anything from before it must be about th=
e old PHP 6. If this RFC were to pass with people voting for 6, then it wou=
ld be pretty clear that anything coming after it was about the new PHP 6.
>>
>> https://www.google.co.uk/search?q=3Dphp6+site%3Abugs.php.net ...
>>
>> Now one can filter additional on date, but the point here is that just
>> starting with the bugs list we have conflicting material that needs to
>> be avoided. PHP6 WAS documented extensively even just on the web site, a
>> lot of that material gets mirrored with more recent timestamps which
>> makes filtering what is new and what is old a lot more difficult. Even
>> PHP7 appears quite often on the website, but fortunately not too often
>> in the bugs list =E2=80=A6
>
> Can=E2=80=99t we just rename the PHP 6 category to =E2=80=9COld PHP 6=E2=
=80=9D on bugs.php.net and be done with it? Or does it not work like that?
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>