Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65267
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7dUBmjT7hmasB17NS91KHxjfuG0d6ahZe-UwzjksQnXQ@mail.gmail.com>
References: <op.wq746rv5idpuyk@damnation.nl.lo.geleia.net>
	<op.wrmidlpiidpuyk@damnation.nl.lo.geleia.net>
	<debcd9bb-79f3-4b2c-aa66-9461018959c9@email.android.com>
	<op.wrmkyvlwidpuyk@damnation.nl.lo.geleia.net>
	<1460659e-237d-4c7c-8cfa-523ec857d646@email.android.com>
	<be26f8067c25e21448eb7f3fc21809b0@mail.gmail.com>
	<CAEZPtU4y_K3FP0KLiLv=a20n1DvPihvknGwYDaX8Vto1DMr3iw@mail.gmail.com>
	<op.wrmo80qgidpuyk@damnation.nl.lo.geleia.net>
	<CAEZPtU7dUBmjT7hmasB17NS91KHxjfuG0d6ahZe-UwzjksQnXQ@mail.gmail.com>
Date: Mon, 28 Jan 2013 17:02:36 +0100
Message-ID: <CAEZPtU4t3jLBu_Tx1LqU9=HiW_d7NnR2K=vsd3wG3z8=9yDjvA@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: Zeev Suraski <zeev@zend.com>, Alan Knowles <alan@roojs.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Jan 28, 2013 at 4:59 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> hi,
>
> On Mon, Jan 28, 2013 at 4:56 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt> wrote:
>> On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye <pierre.php@gmail.com>
>> wrote:
>>
>>> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski <zeev@zend.com> wrote:
>>>>>
>>>>> -----Original Message-----
>>>
>>>
>>>> Can you explain why you think it's a major BC break?  The RFC suggested
>>>> that the BC break would be minimal and that the likelihood a lot of people
>>>> used it is very low.  If you think differently and share it it might put it
>>>> in a different light.
>>>
>>>
>>> Problem is that we do not allow BC break in 5.5, at all, minor or not.
>>> Minor vs major BC is all relative, a minor BC for someone can create
>>> large issues for someone else, that's why we do not allow BC, in
>>> general. Killing some outdated "security" features however may fit
>>> better, but I am really not sure this one is worse the risk.
>>>
>>
>> Sorry, this objection simply is not timely.
>>
>> In order for this voting thing to work, votes have to have a strong degree
>> of finality. It would have to take a pretty strong new fact to overcome that
>> finality. Otherwise, people will not have incentives to look *early* at the
>> RFCs and the discussions will never end.
>>
>> In any case, the interpretation of the release process RFC as to BC breaks
>> has been rather lax. 5.4 introduced pretty disruptive BC breaks like
>> eliminating call-time pass-by-ref and changing the default encoding for
>> htmlentities/htmlspecialchars and new keywords. 5.5 will also introduce a
>> few (look at UPGRADING).
>
> I did not see any but the one about ini options we wanted to kill since years.
>
> If we introduced BC breaks other than those, then we'd to review them
> and see why they have been introduced. But one thing is clear: we do
> not allow BC breaks between 5.x and 5.x+1.

ok, reading the list, there is nothing remotely comparable to what you
propose. However that's a non issue for 5.5 as this RFC only
introduces a strict warning. I would suggest to modify it to specify
that the removal will happen in the next major version.

--
Pierre

@pierrejoye