On 30/03/2015 19:50, Stanislav Malyshev wrote:
Hi!
I tend to agree that it would be easier for all parties if we stop
adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer working
on a project, and you noticed there's some small functionality missing
that would improve things a lot for you - like parameter to some
function or returning some value that is missing. You could easily
contribute it, but if it can't go in minor version there's no point for
you to even bother. Because even if your org is super-up-to-date, they
run 5.6, most realistically - 5.5, and if it's like the majority - it'd
be 5.4 and worse. You could hope to convince your bosses and your ops to
go to 5.6 and keep it reasonably updated within 5.6, but if the only
addition you can make is 7.1, it's the lost cause - by the time your org
could go to 7.1 your project will be long done (or at least long
designed to work without this new feature) and you may be already
working in another company.
If an organisation has standardised on an old version of PHP, there's a
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
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.
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 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).
As everything can be considered as beeing a BC break for at least
someone on Earth, I admit it is hard to understand the meaning of "small
self-contained additions in a micro version" :-p
I do not think we should consider adding functions/options "BC break",
not by any sane definition of it. Of course, nothing prevents somebody
from using insane definitions, but it's of no concern to us.
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
namespace "php\", but it remains unused. So if functions can be added at
any time, the only way to guarantee your code won't break on a patch
upgrade is to treat the entire global namespace as additionally
reserved. I don't think it's at all "insane" to say that a patch version
shouldn't usurp non-reserved names.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
