From: Adam Dickmeiss > Bundling gives many problems. So if a Unix machine has libxml/libxslt > installed (most do) and if that version is supported by PHP the configure > should use that (and not a bundled version). If the PHP people > only allows a very strict set of libxml versions that's a sign > of a problem in ext/xml.* (not in libxml). libxml API doesn't change.
I am not suggesting that we restrict the versions of libxml that people can use. The API calls may not change, but the logic within can and does. Without being able to say that versions x,y,z are supported, what is considered a PHP bug and what is considered a change from libxml (and how can we tell). We are going to be right back to bug reports where people say things are broken when it is really that they are running newer/different versions of libxml. Who decides which is right? Are all the extension maintainers supposed to get togther agree to an upgrade and then start writing custom xml code in order to support the older versions and not break BC? Do you know how many times I have gone through different versions of libxml souce code from bug reports when it ended up being changes within libxml. It was a pain to deal with when there is a single extension using it, but now there are currently 3 that depend on it, 1 that uses it but can use expat, and another one on its way that will depend upon it. It could turn into a nightmare. All I am suggesting is that there is a version(s) - could be more than one - that the extensions are based on and tested against. If people are running something different and the behavior of the library has changed it is not a bug in PHP, so they have the option to live with the changed behavior or run with a supported version. Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
