Hi! > If an organisation has standardised on an old version of PHP, there's a
By "old" you're meaning current stable, I presume. > fair chance that the builds they are using are not from php.net, but > from their OS distribution. As has been mentioned here before, these There are no builds on php.net, except for windows.php.net. Most organizations I've encountered indeed use either distros or their own distro-like packages (which usually mimick distro ones but have modifications like additional packages, tweaking paths, adding/removing configs or data, etc.). > generally track a particular patch release and cherry-pick fixes - > Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official > 5.5.23, for instance. Anyone working in such an environment won't > receive the benefit of a new feature however far it is backported. As per above, it's much easier to get 5.5.23 installed in the org than 7.1. I'm not overly familiar with particulates of Debian policies, but if they have whole distro sitting on 5.5.9 when there's 5.5.23 out it's bad, as their customers do not get bugfixes which may be essential for them. I sincerely hope it's not the case. In any case, burden of creating 5.5.23 package from debian 5.5.9 package is very low, most competent ops would be able to do this, and the risk of following 5.5 line is not comparable to the risk of switching from 5.5 to 7.1. > The obvious alternative avenues are to write a forward-compatible > userland version, or package an extension, both of which are likely to > reach a larger audience than a tail-end release like 5.5.23. I'm not sure how you mean to write an extension that would add an option to json_encode for example. > I can certainly see value in a special case for including things in both > 5.6 and 7.x, both before and after 7.0 is released, but the the case for > backporting anything other than a genuine bug fix to 5.5.x right now > seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0 > is released (by which point 5.6.x will presumably be in its > security-only phase). That means right now any enhancement somebody would propose would be just released somewhere towards the end of next year. And since nobody switches instantly, especially to the next major, their timeframe to use it would be something like 4-5 years. I would have zero motivation as a userland developer to work on a small change like adding an option that I could benefit from in 5 years maybe. Would you? > The problem is that there is no way to know, as a user, which function > names may become reserved in the future. There is an officially reserved That's true in general. But if you name your function something like get_error_handler or mysql_connect_something, you must know you're on a shaky ground. The argument "we can not add anything in the main namespace because somebody could have named function exactly the same" sounds hollow to me. Of course, for some cases it must be true, but most people that don't use classes long learned to prefix or namespace their functions, and And, of course, this does not apply to adding options, etc. > reserved. I don't think it's at all "insane" to say that a patch version > shouldn't usurp non-reserved names. I think in this form it is. There are no "reserved names" in functions, and if you use mysql_* namespace functions and it clashes with functions added by mysql extension, it's your fault. Same for other obvious cases. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
