Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87844
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: "'Nikita Popov'" <nikita.ppv@gmail.com>
Cc: "'Adam Harvey'" <aharvey@php.net>,
	"'Christoph Becker'" <cmbecker69@gmx.de>,
	"'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>
In-Reply-To: <CAF+90c-KkntMjB9H+zm87XqY24-zqWHmP_mLF00qm-pMqaxkWQ@mail.gmail.com>
Date: Fri, 21 Aug 2015 22:37:00 +0200
Message-ID: <036401d0dc51$23f45060$6bdcf120$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH7++SmR5Qqa5F1jGgVRfCNseMOmgMakR6SAY8BXI8BLOfZNwFYh0tDAgjcCuECSonbqgI9gLOFnVKXOUA=
Content-Language: en-us
Subject: RE: [PHP-DEV] libpcre version requirements
From: anatol.php@belski.net ("Anatol Belski")



> -----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
>=20
> On Fri, Aug 14, 2015 at 1:25 AM, Anatol Belski <anatol.php@belski.net>
> wrote:
>=20
> >
> >
> > > -----Original Message-----
> > > From: adam@adamharvey.name [mailto:adam@adamharvey.name] On
> Behalf
> > > Of Adam Harvey
> > > Sent: Thursday, August 13, 2015 8:44 PM
> > > To: Christoph Becker <cmbecker69@gmx.de>
> > > Cc: Anatol Belski <anatol.php@belski.net>; PHP internals
> > > <internals@lists.php.net>
> > > Subject: Re: [PHP-DEV] libpcre version requirements
> > >
> > > On 13 August 2015 at 04:35, Christoph Becker <cmbecker69@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 =E2=80=94 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
> >
>=20
> There already was some discussion about bumping the libpcre version =
for 5.6. I'll
> quote what I said back then:
>=20
> > [...] 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.
>=20
> and
>=20
> > 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.
>=20
> 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.
>=20
> 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.
>=20
> Let's bump this. If you install PHP 7 in 2016 you should *not* have to =
deal with a
> PCRE version released in 2006.
>=20
Yeah, I read this discussion here =
http://grokbase.com/t/php/php-internals/142wrqvs7p/add-support-for-pcre-m=
arks . 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).=20

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