Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55159D9D.4040001@gmail.com>
References: <547CEB74.9070807@ralphschindler.com>
	<E77B850D-7984-4583-BCC9-6F706C9FA45E@gmail.com>
	<CAH-PCH61cWgYAVkEkr0cR10h=rq2LdyT+XiDEThWFhw91-NdNA@mail.gmail.com>
	<CAH-PCH51ads43sU_Uue+ctUeeUoZGL5eNkYB4+Bj2RiAHJ7Kuw@mail.gmail.com>
	<CAMUwpuR8_dxha0Ln9=c-VqLOLGnstTXtF2XfGAS=8Zu6YKH14g@mail.gmail.com>
	<54D1BF4B.30008@gmail.com>
	<CAH-PCH7rpdzmjapTsi8B+w=MZWN1pOdbFAH_x_ZVnONkk9g7hw@mail.gmail.com>
	<55158859.5000606@ralphschindler.com>
	<CAH-PCH7y=Rn2DDSyYP4Z0v-f54cWyGLvasAcG5J_ZC48YOm-FQ@mail.gmail.com>
	<55159D9D.4040001@gmail.com>
Date: Fri, 27 Mar 2015 22:08:04 +0100
Message-ID: <CAH-PCH5P4jA1Q+Jay1c5w2-C9F3tW8Sb3KUeE=MP9jKKN3y8sg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b2e4f6446401805124b87a9
Subject: Re: [PHP-DEV] $http_response_header
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b2e4f6446401805124b87a9
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 27, 2015 at 7:12 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> Ferenc Kovacs wrote on 27/03/2015 16:50:
>
>> yeah, but we already mentioned/discussed this that the removal would
>> require introducing another way (eg. adding a method) for fetching the
>> headers.
>> I think that introducing this method can happen in a minor version(without
>> removing the $http_response_header variable), so I will create a pull
>> request and ask Julien about including it in 5.5 and upwards.
>>
>
> I've seen comments to this effect before, and don't really understand the
> motivation for adding functions in patch versions. Personally, I'd never
> rely on such a function, because it would mean my code relied on a version
> spec like "(>= 5.5.23 && < 5.6.0) || >= 5.6.7", which is just horrible.
>

In general this is because we used to do this and because our
releaseprocess rfc allows it.
In this specific case I have a couple of reasons to not wait for the next
minor:
1, 5.7 got voted down, so the next minor will be probably 7.1 and that is
like 1.5-2 years in the future, depending on how much if any delay the 7.0
gets.
2, I could try to argue that this doesn't require an RFC and target 7.0
regardless of the feature freeze (which technically wouldn't be any more
risky than targetting 5.5/5.6 and simply merging up) but that would
probably cause drama and people would use it as precedence to try to get
bigger/more destabilizing changes into 7.0.
3, just bumped into this issue today myself (and the lack of option to
elegantly pass context options to get_headers() aka
https://bugs.php.net/bug.php?id=55716 planning to send a PR for that one
too) and seeing how fell under the radar I tried to see what I can do.


>
> And on the negative side, there's the (admittedly very small) possibility
> of unexpectedly colliding with someone's existing function.
>

yeah, that is always a possibility, usually this is why we look around on
google/github to avoid the common collisions, but technically we don't
consider this BC break in a sense that it is still allowed by the
releaseprocess RFC.


>
> The definition at SemVer.org (I know PHP doesn't officially follow this
> definition, but it's a well-thought out point of reference) makes clear:
>
> > Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
> compatible functionality is introduced to the public API.
>

agree, albeit people rarely follow that properly:
http://massalabs.com/dev/2014/03/12/battle-of-semver.html which is somewhat
defeats the original idea.


>
> Isn't it enough if the new function, and the deprecation of the variable,
> is snuck into 7.0, or added in 7.1?
>

that would be the safest option, I just don't think that in this specific
case there are much risk doing it in a micro.
if it turns out that we have a general consensus about changing our ways, I
would support it (as you can find a bunch of mails/threads from me on this
topic on this list), I just don't think that it is a good idea that
sometimes we allow this to happen without anybody saying a word, and
sometimes when don't.
we should make up our mind and stick to it whatever we end up deciding.

--047d7b2e4f6446401805124b87a9--