Are there any *particular* issues that you are experiencing? We generally do not update bundled libraries on stable versions unless there is a specific reason to do so, as such updates carry stability risks.

Of course we also prefer not to bundle libraries, e.g. in PHP 7.4 libsqlite and libzip will be removed from our distribution. There are currently no plans to remove the bundled libpcre though.

let me word it differently: if there are no issues why does upstream bother with bugfix releases? when updates would carry *serious* stability risks how comes that all the distributions downstream don't face them?

Distributions do face stability risks. That's why distributions commonly do not update libraries wholesale, but instead backport fixes that they consider worthwhile (often only security fixes or issues specifically reported to them) on a case-by-case basis. Of course this depends on the distribution, it's general update policies and package-specific update policies.

Which is why I'm asking whether there are any specific issues you have in mind here that might make a backport necessary.

i just use Fedora over 12 years and for 10 years in production following changelogs in libraries closely and was surprised to find the year 2017 when building with the bundled one

imho at least once per year there should happen a rebase, the majority of userbase has no chance to track down whatever issues root cause and i don#t get "stability risks" which would only point out demand for additional tests which should have been there anyways

but then the test-suite suffers from enough bigger issues starting by more and more stuff ignores environment and the supplied "php.ini" loading the system extensions instead the fresh built ones making a lot of test completly pointless and only get covered when you fire up a rpmbuild for 7.3 on a system where 7.2 is installed

> imho at least once per year there should happen a rebase, […]

Well, Fedora is moving very quickly: two major releases per
year[1].  Other distros are moving much slower; for instance,
Debian's current stable (Stretch) still ships libpcre 8.39-3[2],
which is a patched 8.39 (released 14-June-2016).  And then there
are even LTS releases, such as the still supported Ubuntu 14.04.5
LTS, which ships libpcre 8.31-2ubuntu2.2[3], which is a patched
8.31 (released 06-July-2012).

> […] which would only point out demand for additional tests which
> should have been there anyways

ACK.  However, this world is not perfect.  For instance,
ext/sqlite3 has less than 100 tests[4], resulting in a coverage of
roughly 80%[5], but even 100% wouldn't be sufficient to detect all
potential regressions.

> but then the test-suite suffers from enough bigger issues
> starting by more and more stuff ignores environment and the
> supplied "php.ini" […]

This is already tracked as <https://bugs.php.net/76494>.  Please
keep separate issues separate. :)  And of course, patches are
welcome!

[1] <https://fedoraproject.org/wiki/Releases>
[2] <https://packages.debian.org/stretch/libpcre3-dev>
[3] <https://packages.ubuntu.com/trusty/libpcre3-dev>
[4] <https://github.com/php/php-src/tree/php-7.3.0/ext/sqlite3/tests>
[5] <http://gcov.php.net/PHP_7_3/lcov_html/ext/sqlite3/index.php>

it's fine that it is "tracked"

i reported similar stuff long-ago, nothing happened, when I now run the test suite with 7.3 additional tests use the system installed extensions - so zjijgs are becoming worser and worser over years and tracking / reporting anything related to the test suite is pretty pointless until one fixes the root cause

there is no point at all that any single test ignores the environment

that 
points out a way larger problem because otherwise a lot more tests would fail because they all or none would ignore the environment

Test fails in different environment might witness something bad or something harmless. The test fails should be reported and fixed, especially if one runs them regularly and knows their environment. Even one can file test fixes which is a much better approach. The more tests pass, the more environments are tested - the more benefit is for everyone, that is always encouraged!

If there are some test fails, please report them or better provide patches :) Sure there can be test fails with say a very recent library versions, which need to be fixed, but also with very ancient disribution versions like CentOS or Debian stable/old stable, which not worth the effort. PHP 5.4 that has all test passing say on Debian stable  is incomparable to PHP 7.3 on the same Debian stable. Everything has its compatibility range and so is it.

Since we don't hear about any concrete issue, this is a non issue. If you have any suggestions on how to change the handling of libraries compatibility, you're free to discuss on internals or write an RFC.

Thanks.

"If there are some test fails, please report them or better provide patches" is a joke

what if you guys just replay the build like https://bugs.php.net/bug.php?id=76494 and you see at yourn own that the system extensions are loaded instead the fresh built one

frankly as i reported all openssl test failing there was even argue left and right that --with-openssl=shared,/usr which is kinda funnny at a point of time having that everywhere in production