> -----Original Message----- > From: Nikita Popov [mailto:nikita....@gmail.com] > Sent: Friday, August 21, 2015 3:14 PM > To: Anatol Belski <anatol....@belski.net> > Cc: Adam Harvey <ahar...@php.net>; Christoph Becker > <cmbecke...@gmx.de>; PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] libpcre version requirements > > On Fri, Aug 14, 2015 at 1:25 AM, Anatol Belski <anatol....@belski.net> > wrote: > > > > > > > > -----Original Message----- > > > From: a...@adamharvey.name [mailto:a...@adamharvey.name] On > Behalf > > > Of Adam Harvey > > > Sent: Thursday, August 13, 2015 8:44 PM > > > To: Christoph Becker <cmbecke...@gmx.de> > > > Cc: Anatol Belski <anatol....@belski.net>; PHP internals > > > <internals@lists.php.net> > > > Subject: Re: [PHP-DEV] libpcre version requirements > > > > > > 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. > > > > What about the other 65% of the market share where we have no idea > > what happens? Well, some of them are Windows where bundled PCRE is > > used, but the rest is like UNIXes, maybe they're 50/50 or alike. > > > > Besides that - an average user won't even have gcc installed to use > > the bundled PCRE or not, and what packagers would do - yep, that's a > question. > > However distributions usually enforce shared libs usage for the exact > > reason to centralize delivery of the (security) updates. > > > > I would suggest to make this move (raising the PCRE version to 7 or 8) > > in master after 7.0 is branched. Then there were enough time to see > > how 7.0 is being handled, to get feedback on that change and to react > > accordingly, if needed. > > > > Regards > > > > Anatol > > > > There already was some discussion about bumping the libpcre version for 5.6. > I'll > quote what I said back then: > > > [...] I think the low version requirement is bad for other reasons: > There's a big gulf in terms of both features and bug fixes between PCRE 6.6 > and > what PHP currently bundles. It's a bit ridiculous that you can end up using a > PHP > version from 2014 together with a decade old PCRE version. > > and > > > It would still be nice to increase the minimum version number [...], > because allowing prehistoric PCRE versions in a new release makes zero sense. > I > recommend at least 8.10 because it both supports marks and - more relevantly > to most users - supports UCP mode, which PHP uses by default (if available). > UCP > mode can significantly change the behavior of PCRE with the /u modifier, as > such guaranteeing a minimum version of 8.10 will also guarantee a somewhat > consistent /u behavior. > > Basically, if we allow a too broad range of PCRE versions, we also allow a > broad > range of behavior people have to deal with. If people use the /u modifier, > they > will get significantly (and at the same time subtly) different behavior if > PHP was > linked against libpcre newer or older than 8.10. > > Distros that will ship with PHP 7 will also ship with new PCRE versions. > External package repositories with PHP 7 will also have newer PCRE versions. > People compiling themselves use the bundled version. > > Let's bump this. If you install PHP 7 in 2016 you should *not* have to deal > with a > PCRE version released in 2006. > Yeah, I read this discussion here http://grokbase.com/t/php/php-internals/142wrqvs7p/add-support-for-pcre-marks . Seems it was not finished for some reasons.
I was mentioning "if it doesn't block the future development" exactly for the reason to hear if there's something. Now turns out there are at least two issues (count yours and Christoph's one) requiring a newer PCRE. Nevertheless - I'd prefer to keep the current situation for 7.0 and do it directly in master after 7.0 was branched which is merely a month away. Primarily to keep 7.0 compatible in as much areas as possible. Also worried a bit about that other 60% from the stats which are not Linux, Linuxes look actually good having >8.10 even for old stable. But that also means - keeping or not an option to use a lower version doesn't really hurt (at least for the popular distros like Debian, Ubuntu, Fedora). Also about the future work - IMHO it would make sense to start a port for PCRE2 at some point in autumn (and I'm intended to if no one started earlier) to target 7.1 or later. Regarding PCRE - it most likely won't get any new features but bug fixes only, PCRE2 is what were future oriented. 7.0 won't arrive in the distros earlier than in a yeah, or alike. And by that time that can be completely another priority. So concluding - preferably were to keep the PCRE version for 7.0 and raise in master, unless you see some hard issue or want to make use of "new" features in PCRE 8.x that can't wait anymore, then please do now. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
