Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87740
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
Message-ID: <55CC80FC.5070306@gmx.de>
Date: Thu, 13 Aug 2015 13:35:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Anatol Belski <anatol.php@belski.net>, 
 'PHP internals' <internals@lists.php.net>
References: <55CA26DF.3030109@gmx.de> <03dd01d0d476$c75b6730$56123590$@belski.net> <55CA646F.8020506@gmx.de> <040101d0d4ca$656f4e20$304dea60$@belski.net>
In-Reply-To: <040101d0d4ca$656f4e20$304dea60$@belski.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] libpcre version requirements
From: cmbecker69@gmx.de (Christoph Becker)

On 12.08.2015 at 08:44, Anatol Belski wrote:

>> -----Original Message-----
>> From: Christoph Becker [mailto:cmbecker69@gmx.de]
>> Sent: Tuesday, August 11, 2015 11:09 PM
>> To: Anatol Belski <anatol.php@belski.net>; 'PHP internals'
>> <internals@lists.php.net>
>> Subject: Re: [PHP-DEV] libpcre version requirements
>>
>> Still, I would suggest to raise the libpcre requirements to PCRE >= 8.0 for PHP 7.0
>> or at least for PHP 7.1.
>
> [...] However look - http://w3techs.com/technologies/details/os-linux/all/all . From those, CentOS 5/6 releases are not even a year old and contain 6.6, 7.x but take 20% of all the Linux market share. Note that according to that Linux takes only 35.9% of it. Now, say disregarding CentOS 5 and other rare/too old platforms, the other 65% of the usages are not taken into account. So how much loss on PHP7 adoption would happen, is a question. Maybe there are other stats, just operating on what is available.
> 
> On the other hand  - as with the bug #70232, is it really worth disabling the whole PCRE just to be sure one bug is fixed? I would see it as not being such.  It is clear, that no distro will suddenly be upgrading from say PHP 5.3 to PHP7 in an older branch, but keeping as much compat as possible will allow third party repositories to still provide PHP7 there. This is at least my reason to say the version shouldn't be raised - as it shouldn't go beyond 7.x at least because of CentOS 6, and then it is probably useless to do it ATM. As long as it doesn't block the work towards future, at least.

Well, then it might be best to leave the requirements as they are for
now. :)

-- 
Christoph M. Becker