Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85604
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.43 as permitted sender)
Message-ID: <551AFF0B.7020903@gmail.com>
Date: Tue, 31 Mar 2015 13:09:47 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Rowan Collins <rowan.collins@gmail.com>, 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> <551A8B42.6080603@gmail.com>
In-Reply-To: <551A8B42.6080603@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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.

I think this is all wrong, because I don't see how they can do better
testing with random set of patches than with real release version, but
that's beside the point. The point is it's very easy to make a
deployable package from php.net source pack, but it's much harder to
move an organization to different version that may cause BC breaks and
other disruption. It's both technical and organizational - try to
propose moving software from version 5.5.23 to 5.5.24 and from 5.x to
7.x and ask anybody which is riskier. Almost universally you'd be told
the latter is much riskier.

> 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.

Switching to 5.6 would be useless since what is being propose it to ban
any enhancements up to 7.1.

> Well, you could fork the JSON extension, I guess. But yes, not all
> options are available in all cases.

For most enhancements, no options but "wait for a couple of years" are
available unless you want to maintain a full-blown php fork.


> 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.

Then we agree. But the proposal here was to ban all enhancements in
released versions. This is just wrong, and I am glad you support it.

> 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.

Depends on "features". In principle I'd be fine with enhancement going
only into 5.6, but given its abysmal adoption so far, practically I can
see the case for some stuff in 5.5 too. But I recognize it's chicken and
egg problem, so if we can reach consensus on 5.6, I can live with that.

> 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.

This is a regular "version requirement" concern which ops should be well
familiar with and be able to handle.

> prefixes like error_*, file_*, etc. So, for simplicity, you might as
> well treat the global namespace as out of bounds.

In my code, I'd be wary of putting non-prefixed functions into global
namespace. PHP versions is only one reason - if two libraries have
error_report() function, they never can be used together, not a good
thing. I'd rather call it my_library_error_report() if for some reason I
can't namespace it properly.

-- 
Stas Malyshev
smalyshev@gmail.com