Re: libpcre version requirements

From: Date: Thu, 13 Aug 2015 18:44:16 +0000
Subject: Re: libpcre version requirements
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-87747@lists.php.net to get a copy of this message
On 13 August 2015 at 04:35, Christoph Becker <cmbecker69@gmx.de> wrote: > On 12.08.2015 at 08:44, Anatol Belski wrote: >> >> [...] 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. :) I'm still OK requiring 8.00 in PHP 7.0, personally — even that is almost six years old, and users on older distros and OSes can use the bundled libpcre. It's not like this is going to break the common case where the user doesn't set any specific PCRE flags in configure, and I don't think it's unreasonable to expect third party packagers to use a bundled library if they're building on that old a system. They're effectively shouldering the burden of providing security updates for PHP regardless of what the distro does. Adam

« previous php.internals (#87747) next »