On Fri, Mar 27, 2015 at 7:12 PM, Rowan Collins <rowan.coll...@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.
