Re: What's our official stance on small self-contained additions in a micro version

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]