Just to add my experience (even though the original poster explicitly
asked for single extensions not to be mentioned) from a
not-completely-unrelated problem: some extensions have an "internal"
version number that is not always updated when the userland API of said
extension is changed - see eg. Json and the recent change of behavior on
decoding scalar values.
This makes it very hard for people maintaining php libraries to code
defensively and test the version in use to enable workarounds:
- the extension version number is useless (if not managed correctly)
- the php version number is useless, since the extension might have been
downloaded and compiled from pecl and not correspond to the version that
is distributed with the core
The only option left in this situation is to test the functionality
needed first, then use it, much as it is done in js - a very sad state
of things... (of course I would not recommend disabling upgrade /
backport of a php extension from pecl as a solution)
The fact that the extension lives in both pecl and core and the two
might be slightly out of sync does not help at all when trying to find
out the cause of regressions...
Bye
Gaetano
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
