Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72085
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.181 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAEZPtU61Rp6icVF80+cJxHetbQZ0i_UEFMuS-tOBLMv6RcAxPw@mail.gmail.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
 <52EAF0A3.2000001@oracle.com> <1d5850561e0ef9e7739c7e7b7b0448d0.squirrel@webmail.klapt.com>
 <52EC0B34.8080109@oracle.com> <d41c0659b516306ea4eb534723f3d771@mail.gmail.com>
 <1391279853.2941.307.camel@guybrush> <52ED6664.7080906@sugarcrm.com>
 <alpine.DEB.2.10.1402030947450.6067@whisky.home.derickrethans.nl> <CAEZPtU61Rp6icVF80+cJxHetbQZ0i_UEFMuS-tOBLMv6RcAxPw@mail.gmail.com>
Date: Mon, 3 Feb 2014 14:05:30 +0100
Message-ID: <CAMUwpuQnarzCXNzU7B9M0usZc=BuQKErMK9fJdOxRpGzmYHVaA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Derick Rethans <derick@php.net>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	=?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	Zeev Suraski <zeev@zend.com>, Christopher Jones <christopher.jones@oracle.com>, 
	Anatol Belski <anatol.php@belski.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: jpauli@php.net (Julien Pauli)

On Mon, Feb 3, 2014 at 10:53 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Mon, Feb 3, 2014 at 10:49 AM, Derick Rethans <derick@php.net> wrote:
>
>> Heh. That happens already now too...
>
> Not really, except in extreme cases where one tries to block a thing
> using one way or another. However I do not think either we need 2/3 to
> change something in the Engine, core or extension but what is actually
> exposed to the users, which we have to maintain for BC reasons for
> years. On the other hand, internals are more flexible and can be
> changed without impacting existing applications.
>
>> So I'd rather be more descriptive.
>> The release process and voting RFCs are so incredible vague.
>
> The only vague part is about major releases (like 6) as it is merely
> impossible to define a time frame for them. Everything else is rather
> clear and has worked quite well for the numerous submitted RFCs.
>
> That being said, we can clarify the major release process and try to
> put some time frames in them. But I am not in favor of over formalized
> the other parts and try to keep relying on common senses, even if the
> latter has some hard time lately.

Ok to clarify it, sure.

I'm all +1 to branch 6 after 5.6 is released (say during 2014) , we
have some talented contributors, some ideas, some motivation feeling
and we are at PHP5 + 10 years.

I think we'll need at least 2 years developement, if not 3.
All this depends on what we want to do with PHP6, and this must be
community debatted, open.

I hope people will understand issues of PHP6, and won't start drama
again and again :-p

Julien