Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85581
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
Message-ID: <551A8B42.6080603@gmail.com>
Date: Tue, 31 Mar 2015 12:55:46 +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> <5519B3E3.1070102@gmail.com> <5519C9E0.6010001@gmail.com>
In-Reply-To: <5519C9E0.6010001@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)

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]