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. Nikita
