On 13 August 2015 at 04:35, Christoph Becker <cmbecke...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
