Re: libpcre version requirements

On 21.08.2015 at 22:37, Anatol Belski wrote: >> -----Original Message----- >> From: Nikita Popov [mailto:nikita.ppv@gmail.com] >> Sent: Friday, August 21, 2015 3:14 PM >> To: Anatol Belski <anatol.php@belski.net> >> Cc: Adam Harvey <aharvey@php.net>; Christoph Becker >> <cmbecker69@gmx.de>; PHP internals <internals@lists.php.net> >> Subject: Re: [PHP-DEV] libpcre version requirements >> >> 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. Would it be an acceptable compromise for everybody to stick with the current *requirements* for now, but to document[1] that PCRE >= 8.10 is *recommended* for PHP 5.6 and 7.0? [1] <http://php.net/manual/en/pcre.installation.php> -- Christoph M. Becker