Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87864
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Christoph Becker'" <cmbecker69@gmx.de>,
	"'Nikita Popov'" <nikita.ppv@gmail.com>
Cc: "'Adam Harvey'" <aharvey@php.net>,
	"'PHP internals'" <internals@lists.php.net>
References: <55CA26DF.3030109@gmx.de> <03dd01d0d476$c75b6730$56123590$@belski.net> <55CA646F.8020506@gmx.de> <040101d0d4ca$656f4e20$304dea60$@belski.net> <55CC80FC.5070306@gmx.de> <CADajX4CcuDJLQtEjcS+-O_Dr9yYerRe4M=hyn1oP_Bggifmp8A@mail.gmail.com> <066a01d0d61f$4937d370$dba77a50$@belski.net> <CAF+90c-KkntMjB9H+zm87XqY24-zqWHmP_mLF00qm-pMqaxkWQ@mail.gmail.com> <036401d0dc51$23f45060$6bdcf120$@belski.net> <55D79858.8080506@gmx.de>
In-Reply-To: <55D79858.8080506@gmx.de>
Date: Sat, 22 Aug 2015 16:52:48 +0200
Message-ID: <04ac01d0dcea$386a6860$a93f3920$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH7++SmR5Qqa5F1jGgVRfCNseMOmgMakR6SAY8BXI8BLOfZNwFYh0tDAgjcCuECSonbqgI9gLOFAT/6D6UCYLLr55021zuA
Content-Language: en-us
Subject: RE: [PHP-DEV] libpcre version requirements
From: anatol.php@belski.net ("Anatol Belski")

Hi Christoph,

> -----Original Message-----
> From: Christoph Becker [mailto:cmbecker69@gmx.de]
> Sent: Friday, August 21, 2015 11:30 PM
> To: Anatol Belski <anatol.php@belski.net>; 'Nikita Popov'
> <nikita.ppv@gmail.com>
> Cc: 'Adam Harvey' <aharvey@php.net>; 'Christoph Becker'
> <cmbecker69@gmx.de>; 'PHP internals' <internals@lists.php.net>
> Subject: Re: [PHP-DEV] libpcre version requirements
>=20
> On 21.08.2015 at 22:37, Anatol Belski wrote:
>=20
> >> -----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.
>=20
> Would it be an acceptable compromise for everybody to stick with the =
current
> *requirements* for now, but to document[1] that PCRE >=3D 8.10 is
> *recommended* for PHP 5.6 and 7.0?
>=20
A documentation can never hurt. For the case the requirement wouldn't be =
changed, it's of course even better to have a doc line, IMHO.

Regards

Anatol