> -----Original Message----- > From: Christoph Becker [mailto:cmbecke...@gmx.de] > Sent: Tuesday, August 11, 2015 11:09 PM > To: Anatol Belski <anatol....@belski.net>; 'PHP internals' > <internals@lists.php.net> > Subject: Re: [PHP-DEV] libpcre version requirements > > On 11.08.2015 at 22:46, Anatol Belski wrote: > > >> -----Original Message----- > >> From: Christoph Becker [mailto:cmbecke...@gmx.de] > >> Sent: Tuesday, August 11, 2015 6:46 PM > >> To: PHP internals <internals@lists.php.net> > >> Subject: [PHP-DEV] libpcre version requirements > >> > >> What is the minimum libpcre version that is supported as external > >> libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 > >> (2006-02-06), but is this still valid and do we really have to support > >> such old > versions? > >> > >> I'm asking because of bug #70232 which can easily be fixed, but that > >> requires PCRE 8.00 (2009-10-19). If we have to support older PCRE > >> versions, we'd probably need a fallback to the current behavior > >> (which would obviously keep the bug). > > > > IMHO the dependent version shouldn't be raised. But not sure what is meant > by "implementing for lower versions". Probably if it's missing in PCRE, so is > it. > We should avoid reimplementing it, but just doing what is done in the other > exts, > fe curl. Users can choose to upgrade the dependency or to miss the feature. So > a compile time PCRE version check were enough. > > The difference to cURL, AIUI, is that this is not about an option that can be > supplied by the user (and checked for existance in user-land code, by e.g. > defined(CURLOPT_*)), but rather something that is for internal use only, and > therefore much less obvious for user-land developers. > > IOW: fixing bug #70232 is trivial, but the bug would still persist for > libpcre 7.2 - > 7.9. If that's not regarded as a general issue, I'm fine with it. > > Still, I would suggest to raise the libpcre requirements to PCRE >= 8.0 for > PHP 7.0 > or at least for PHP 7.1. > Yeah, it's different from curl in some ways. 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. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
