Stanislav Malyshev wrote on 30/03/2015 23:10:
Hi!
If an organisation has standardised on an old version of PHP, there's a
By "old" you're meaning current stable, I presume.
No, current stable is 5.6.x; people have been talking about backporting
to 5.5.x (which has 2 months of "active support" remaining according to
http://php.net/supported-versions.php).
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.).
Yes, "builds" is perhaps not the right word, but you got my meaning OK.
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
That's not quite how it works; the distro package maintainers maintain a
sort of forked version of upstream code, combining a well-tested
upstream release with a set of patches, many of which will be backported
fixes from newer releases. So the current package in Ubuntu 14.04 LTS
[see http://packages.ubuntu.com/trusty/php5] is "5.5.9+dfsg-1ubuntu4.7",
and the Ubuntu Changelog shows 12 releases, mostly for security patches,
which is nearly as many as there have been upstream releases.
the risk of following 5.5
line is not comparable to the risk of switching from 5.5 to 7.1.
This is a straw man as far as the points I made are concerned. I'm
talking about the risk of switching from 5.5 to 5.6, which is pretty low.
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.
Well, you could fork the JSON extension, I guess. But yes, not all
options are available in all cases.
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?
That's completely the opposite of what I said. I said I *do* think
adding small features to 5.6 may be justified, since 7.0 will be a more
painful upgrade.
The type of backporting I'm questioning is adding features to 5.5.x,
when we have 5.6.x released, and 7.0.x in preparation. And, *after* the
7.1.0 release towards the end of next year, I would not expect features
to be backported to 7.0.
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.
No, indeed. There, the cost is only on the developer having to ensure
that they don't deploy code relying on the new option to a server one
patch version too old.
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.
That depends what you mean by "obvious". You could consider every
function name beginning str_* or array_* as "obviously" reserved for
future built-in functionality; but then you've got to reserve dozens of
prefixes like error_*, file_*, etc. So, for simplicity, you might as
well treat the global namespace as out of bounds.
I think a patch version should generally be installable without
thoroughly reading the Changelog, except in rare and widely publicised
situations where a security fix was found to be impossible without
breaking something. You shouldn't have to risk your code breaking
because you missed the line "new function get_error_handler()" somewhere
amongst the memory leak fixes and security patches.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
