Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
Message-ID: <5519B3E3.1070102@gmail.com>
Date: Mon, 30 Mar 2015 21:36:51 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com> <55193060.5000804@php.net> <CAH-PCH6Q7FA536v8qABLSC9C2C0ufXOo2e0eWcB2QfJcLv+gSQ@mail.gmail.com> <CAMUwpuRYMxX9paP0y0-DHAdX4=TX7qeO8wS7Q_9QsU+A3x-rPw@mail.gmail.com> <55199AE8.4090100@gmail.com>
In-Reply-To: <55199AE8.4090100@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: rowan.collins@gmail.com (Rowan Collins)

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]