Hi all!
What is the minimum libpcre version that is supported as external
libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6
(2006-02-06), but is this still valid and do we really have to support
such old versions?
I'm asking because of bug #70232 which can easily be fixed, but that
requires PCRE 8.00 (2009-10-19). If we have to support older PCRE
versions, we'd probably need a fallback to the current behavior (which
would obviously keep the bug).
--
Christoph M. Becker
What is the minimum libpcre version that is supported as external
libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6
(2006-02-06), but is this still valid and do we really have to support
such old versions?
CentOS/RHEL 5 provides libpcre 6.6, which is probably where that
specific minimum version comes from. Someone out there is probably
still building packages that rely on this.
I'm asking because of bug #70232 which can easily be fixed, but that
requires PCRE 8.00 (2009-10-19). If we have to support older PCRE
versions, we'd probably need a fallback to the current behavior (which
would obviously keep the bug).
I guess the question's really whether we should still support an
external libpcre that old, since we bundle much newer versions. I
think the argument against changing it has always been that it works
and we didn't need anything newer, but if we have a reason now then
that doesn't really hold.
One problem is that I don't think we can really change the minimum
requirement on a stable branch, so for 5.5 and 5.6 we're going to have
to implement something that works with older versions regardless, but
I'd be for bumping the minimum version requirement for 7.0 if it makes
the code cleaner (on that branch, at least) moving forward.
Adam
What is the minimum libpcre version that is supported as external
libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6
(2006-02-06), but is this still valid and do we really have to support
such old versions?CentOS/RHEL 5 provides libpcre 6.6, which is probably where that
specific minimum version comes from. Someone out there is probably
still building packages that rely on this.
FWIW, this PCRE 6.6 requirement has been introduced with commit 1ad21d9b
in May 2006, thus before CentOS/RHEL 5.0 had been released. It seems to
me that nobody simply touched this requirement since then. Actually
some features already require more recent libpcre, for instance, the \K
modifier requires PCRE 7.2.
I'm asking because of bug #70232 which can easily be fixed, but that
requires PCRE 8.00 (2009-10-19). If we have to support older PCRE
versions, we'd probably need a fallback to the current behavior (which
would obviously keep the bug).I guess the question's really whether we should still support an
external libpcre that old, since we bundle much newer versions. I
think the argument against changing it has always been that it works
and we didn't need anything newer, but if we have a reason now then
that doesn't really hold.One problem is that I don't think we can really change the minimum
requirement on a stable branch, so for 5.5 and 5.6 we're going to have
to implement something that works with older versions regardless, but
I'd be for bumping the minimum version requirement for 7.0 if it makes
the code cleaner (on that branch, at least) moving forward.
I don't know if we can implement a fully working fallback for PCRE < 8
in a viable way. Actually, PCRE_NOTEMPTY_ATSTART had been added to
libpcre to solve the issue with \K for /g[1]. Note the wording of the
commit message:
| Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly
| implement the /g option in pcretest when the pattern contains \K,
| [...]
My best idea so far is to use PCRE_NOTEMPTY_ATSTART and to fallback to
PCRE_NOTEMPTY, if the former is not available. Of course the bug would
persist for old libpcre, but \K will not be effective for PCRE 6.6 anyway.
[1]
https://lists.exim.org/lurker/message/20090911.102109.6e80cce4.pt-BR.html
--
Christoph M. Becker
Hi all,
I'm asking because of bug #70232 which can easily be fixed, but that
requires PCRE 8.00 (2009-10-19). If we have to support older PCRE
versions, we'd probably need a fallback to the current behavior (which
would obviously keep the bug).I guess the question's really whether we should still support an
external libpcre that old, since we bundle much newer versions. I
think the argument against changing it has always been that it works
and we didn't need anything newer, but if we have a reason now then
that doesn't really hold.One problem is that I don't think we can really change the minimum
requirement on a stable branch, so for 5.5 and 5.6 we're going to have
to implement something that works with older versions regardless, but
I'd be for bumping the minimum version requirement for 7.0 if it makes
the code cleaner (on that branch, at least) moving forward.I don't know if we can implement a fully working fallback for PCRE < 8
in a viable way. Actually, PCRE_NOTEMPTY_ATSTART had been added to
libpcre to solve the issue with \K for /g[1]. Note the wording of the
commit message:| Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly
| implement the /g option in pcretest when the pattern contains \K,
| [...]My best idea so far is to use PCRE_NOTEMPTY_ATSTART and to fallback to
PCRE_NOTEMPTY, if the former is not available. Of course the bug would
persist for old libpcre, but \K will not be effective for PCRE 6.6 anyway.
Isn't it normal that PHP would not support features that underlying libs do
not
support? We have number of such functions. Isn't it the reason why
phpinfo()
shows underlying library versions?
Distributions prefer to use system's libraries. I suppose question is if
PHP
supports older systems such as RHEL/CentOS 5 or not. They are used widely.
I prefer to support them if it is possible/feasible. Features that are not
supported
by libs could be documentation issues. IMO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Distributions prefer to use system's libraries. I suppose question is if
PHP
supports older systems such as RHEL/CentOS 5 or not. They are used widely.
I prefer to support them if it is possible/feasible. Features that are not
supported
by libs could be documentation issues. IMO.
BTW, I don't think we should support very old libraries for new major
release.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Distributions prefer to use system's libraries. I suppose question is if
PHP
supports older systems such as RHEL/CentOS 5 or not. They are used widely.
I prefer to support them if it is possible/feasible. Features that are not
supported
by libs could be documentation issues. IMO.
Well, of course we can document all these details, but see, for
instance, http://www.php.net/manual/en/libxml.constants.php – hard to
document, hard to remember, and hard to implement for apps which are
supposed to run in different environments. At least we should try to
reduce the divergence as much as possible (i.e. without introducing BC
breaks in revisions).
BTW, I don't think we should support very old libraries for new major
release.
ACK. IMHO requiring PCRE >= 8.0 would be fine for PHP 7.
--
Christoph M. Becker
Hi Christoph,
-----Original Message-----
From: Christoph Becker [mailto:cmbecker69@gmx.de]
Sent: Tuesday, August 11, 2015 6:46 PM
To: PHP internals internals@lists.php.net
Subject: [PHP-DEV] libpcre version requirementsHi all!
What is the minimum libpcre version that is supported as external libpcre for
ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still
valid and do we really have to support such old versions?I'm asking because of bug #70232 which can easily be fixed, but that requires
PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd
probably need a fallback to the current behavior (which would obviously keep
the bug).
IMHO the dependent version shouldn't be raised. But not sure what is meant by "implementing for lower versions". Probably if it's missing in PCRE, so is it. We should avoid reimplementing it, but just doing what is done in the other exts, fe curl. Users can choose to upgrade the dependency or to miss the feature. So a compile time PCRE version check were enough.
Regards
Anatol
-----Original Message-----
From: Christoph Becker [mailto:cmbecker69@gmx.de]
Sent: Tuesday, August 11, 2015 6:46 PM
To: PHP internals internals@lists.php.net
Subject: [PHP-DEV] libpcre version requirementsWhat is the minimum libpcre version that is supported as external libpcre for
ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still
valid and do we really have to support such old versions?I'm asking because of bug #70232 which can easily be fixed, but that requires
PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd
probably need a fallback to the current behavior (which would obviously keep
the bug).IMHO the dependent version shouldn't be raised. But not sure what is meant by "implementing for lower versions". Probably if it's missing in PCRE, so is it. We should avoid reimplementing it, but just doing what is done in the other exts, fe curl. Users can choose to upgrade the dependency or to miss the feature. So a compile time PCRE version check were enough.
The difference to cURL, AIUI, is that this is not about an option that
can be supplied by the user (and checked for existance in user-land
code, by e.g. defined(CURLOPT_*)), but rather something that is for
internal use only, and therefore much less obvious for user-land developers.
IOW: fixing bug #70232 is trivial, but the bug would still persist for
libpcre 7.2 - 7.9. If that's not regarded as a general issue, I'm fine
with it.
Still, I would suggest to raise the libpcre requirements to PCRE >= 8.0
for PHP 7.0 or at least for PHP 7.1.
--
Christoph M. Becker
-----Original Message-----
From: Christoph Becker [mailto:cmbecker69@gmx.de]
Sent: Tuesday, August 11, 2015 11:09 PM
To: Anatol Belski anatol.php@belski.net; 'PHP internals'
internals@lists.php.net
Subject: Re: [PHP-DEV] libpcre version requirements-----Original Message-----
From: Christoph Becker [mailto:cmbecker69@gmx.de]
Sent: Tuesday, August 11, 2015 6:46 PM
To: PHP internals internals@lists.php.net
Subject: [PHP-DEV] libpcre version requirementsWhat is the minimum libpcre version that is supported as external
libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6
(2006-02-06), but is this still valid and do we really have to support such old
versions?I'm asking because of bug #70232 which can easily be fixed, but that
requires PCRE 8.00 (2009-10-19). If we have to support older PCRE
versions, we'd probably need a fallback to the current behavior
(which would obviously keep the bug).IMHO the dependent version shouldn't be raised. But not sure what is meant
by "implementing for lower versions". Probably if it's missing in PCRE, so is it.
We should avoid reimplementing it, but just doing what is done in the other exts,
fe curl. Users can choose to upgrade the dependency or to miss the feature. So
a compile time PCRE version check were enough.The difference to cURL, AIUI, is that this is not about an option that can be
supplied by the user (and checked for existance in user-land code, by e.g.
defined(CURLOPT_*)), but rather something that is for internal use only, and
therefore much less obvious for user-land developers.IOW: fixing bug #70232 is trivial, but the bug would still persist for libpcre 7.2 -
7.9. If that's not regarded as a general issue, I'm fine with it.Still, I would suggest to raise the libpcre requirements to PCRE >= 8.0 for PHP 7.0
or at least for PHP 7.1.
Yeah, it's different from curl in some ways. 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.
Regards
Anatol
-----Original Message-----
From: Christoph Becker [mailto:cmbecker69@gmx.de]
Sent: Tuesday, August 11, 2015 11:09 PM
To: Anatol Belski anatol.php@belski.net; 'PHP internals'
internals@lists.php.net
Subject: Re: [PHP-DEV] libpcre version requirementsStill, I would suggest to raise the libpcre requirements to PCRE >= 8.0 for PHP 7.0
or at least for PHP 7.1.[...] 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. :)
--
Christoph M. Becker
[...] 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.
Adam
-----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[...] 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
On Fri, Aug 14, 2015 at 1:25 AM, Anatol Belski anatol.php@belski.net
wrote:
-----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[...] 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
-----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 requirementsOn Fri, Aug 14, 2015 at 1:25 AM, Anatol Belski anatol.php@belski.net
wrote:-----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 requirementsOn 13 August 2015 at 04:35, Christoph Becker cmbecker69@gmx.de
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.
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.
Regards
Anatol
-----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 requirementsThere 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
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-----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 requirementsThere 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?
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
Hi Anatol,
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?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.
I've added the recommendation:
https://svn.php.net/viewvc?view=revision&revision=337590.
What do you mean by "doc line"? A note in UPGRADING?
--
Christoph M. Becker
Hi Christoph,
-----Original Message-----
From: Christoph Becker [mailto:cmbecker69@gmx.de]
Sent: Saturday, August 22, 2015 6:55 PM
To: Anatol Belski anatol.php@belski.net; 'Nikita Popov'
nikita.ppv@gmail.com
Cc: 'Adam Harvey' aharvey@php.net; 'PHP internals' internals@lists.php.net
Subject: Re: [PHP-DEV] libpcre version requirementsHi Anatol,
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?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.I've added the recommendation:
https://svn.php.net/viewvc?view=revision&revision=337590.What do you mean by "doc line"? A note in UPGRADING?
Nope, I meant exactly what you did :)
Thanks
Anatol
Hi Anatol,
Hi Christoph,
-----Original Message-----
From: Christoph Becker [mailto:cmbecker69@gmx.de]
Sent: Saturday, August 22, 2015 6:55 PM
To: Anatol Belski anatol.php@belski.net; 'Nikita Popov'
nikita.ppv@gmail.com
Cc: 'Adam Harvey' aharvey@php.net; 'PHP internals' internals@lists.php.net
Subject: Re: [PHP-DEV] libpcre version requirementsHi Anatol,
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?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.I've added the recommendation:
https://svn.php.net/viewvc?view=revision&revision=337590.What do you mean by "doc line"? A note in UPGRADING?
Nope, I meant exactly what you did :)
Fine. Thanks.
--
Christoph M. Becker