Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99451
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: =?UTF-8?Q?Pedro_Magalh=c3=a3es?= <mail@pmmaga.net>,
 =?UTF-8?Q?Fran=c3=a7ois_Laupretre?= <francois@tekwire.net>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>,
 PHP internals <internals@lists.php.net>
References: <CAJd4=YaMDkocahDE0muQNPYW=vgR_nffJD-CBKic7CnbFPwyyw@mail.gmail.com>
 <eadc5bea-3412-9c9b-faa9-e74b442a6b84@gmx.de>
 <7028fcfd-d47f-c983-510d-eefe4a36cd4a@tekwire.net>
 <CAJd4=YadTb6wspVz7zAVh0wuasZdtCsjMnnER40y_ib3A5QVbw@mail.gmail.com>
Message-ID: <4b3a548c-fd9f-42da-93c7-e8403f065da5@php.net>
Date: Thu, 8 Jun 2017 09:52:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAJd4=YadTb6wspVz7zAVh0wuasZdtCsjMnnER40y_ib3A5QVbw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Hi Pedro,

Le 07/06/2017 à 20:23, Pedro Magalhães a écrit :
> I will not change the target version now during the voting phase. Also 
> because it wouldn't make sense to vote for a feature for 8.0 yet. If the 
> RFC is rejected and the sentiment is that most people would agree with 
> the change but not with the timing, I will propose it again when RFCs 
> for 8.0 are relevant.

I am sorry you take it this way. Voting today on a feature for 8.0 
wouldn't be ridiculous and it would make me change my vote, as most 
others. Instead of nonsense, it would be a sign of maturity for the PHP 
project. It would be great, IMO, to open a 'Approved for 8.0' section on 
the RFC page now, and your RFC could proudly be the 1st one to enter it.

This would prove, IMO again, that we are finally able to think more long 
term than we did in the past. The most interesting proposals for 7.0 
were rejected before it was too late to introduce such disruptive 
changes. They should have been prepared a long time before, introducing 
a compatibility path, so that people could prepare their code. This was 
also one of the reasons for the failure of PHP 6.

So, advertising a future BC break months before a release perfectly 
makes sense. The only risk would be to forget it but, by creating a 
specific section on the RFC page, we ensure it won't. In theory, it 
should even work this way : gather proposals, vote, feature freeze, 
implements PRs, merge them, and, only at this time, start publishing 
alpha, beta, RC, final. We accept changes after publishing alpha because 
most people wake up too late. So, I encourage you again to initiate a 
much more mature way of planning the next major version !

Regards

François