On 21.08.2015 at 22:37, Anatol Belski wrote: >> -----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 >> >> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
