Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85675
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain birkholz.biz does not designate 144.76.185.252 as permitted sender)
Message-ID: <551C5AFB.7090107@birkholz.biz>
Date: Wed, 01 Apr 2015 22:54:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Stanislav Malyshev <smalyshev@gmail.com>, internals@lists.php.net
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com> <551BC7CF.3080309@birkholz.biz> <551C44C7.6060108@gmail.com> <551C48AC.3090908@birkholz.biz> <551C4A60.2050805@gmail.com> <551C5045.3010405@birkholz.biz> <551C56E2.8090100@gmail.com>
In-Reply-To: <551C56E2.8090100@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: dennis@birkholz.biz (Dennis Birkholz)

Hi,

Am 01.04.2015 um 22:36 schrieb Stanislav Malyshev:
>> Debian, Ubuntu and CentOS: ~21,23%
>>
>> (I assume here like Anthony that the installs matching a distribution
>> specific version always come from that distribution).
> 
> Pretty big one, I'd say, but even with this one you only get 1/5. Also,
> as I said, it's very easy to take distro package and repackage it to use
> the source from the same minor but up-to-date patch version.

As I said, I miss-remembered the numbers to be much higher.

>> An addition and a bug fix are different things.
> 
> I know but you said, I'm quoting, "please let the x.y.z versions contain
> only additional (security) fixes" which excluding non-security fixes too.

I tried to indicate with braces around security that general
non-security fixes may be allowed to, but I try to be more explicit next
time ;-)

> Let's consider a somewhat arbitrary example:
> https://github.com/php/php-src/pull/1211
> 
> There's a HTTP status code needs to be added (doesn't matter if new or
> just omitted by oversight). You could have it in next 5.6 version (you
> can have it in use in 3 months realistically - one month for release to
> catch up, 2 months for ops in your project to be confident that new
> patch release doesn't break anything) or you could have it in 2.5 years
> (1.5 years for 7.1 to be released, 1 year - and that's *extremely*
> optimistic - for ops to be ok to switch to a new distro version which
> hopefully - just hopefully, extremely optimistic again - but that time
> ships with 7.1 and not still randomly patched 5.5).

The questions here are:
* will this code break any code running with PHP before that patch?
* does this code change the language in any way?

if any of this is true, I would consider the patch not self-contained
any more.

> For me, it sounds insane that you'd have to wait for so long for such a
> simple thing.
> 
> Of course, instead of status code it could be option support in XML, or
> new function/option support in ICU, or new connection option in mysql.
> Any improvement in the environment - do you want it in PHP in terms of
> several years or in terms of 3 months?

But then using the x.y.z version schema implies something like semver
but in reality we have more like a rolling release.
Instead we should consider having a stable "PHP-next" nightly release
that is something like a stabilized master that gets all changes for the
X.Y+1 release. If you require these little features, you use that, if
you only require security/bug fixes, you stick to the regular x.y.z
releases.

Greets
Dennis