Re: backwards compatibility

Hi Marshall, Marshall Roch wrote:

The PEAR package doesn't list XML_RPC as a dependency, but it tries to use it in Remote.php. If XML_RPC isn't installed, Remote.php says that

This is a bug - however, I'm pretty sure that XML_RPC is an optional dependency. If you set extension=php_xml-rpc.dll (windows) or .so (unix), in php.ini, won't Remote.php use that extension?

you can't use the remote functions. The problem is that there is no way to make sure that the correct version is installed, which limits the possibility of improving other classes. In my case, I want to move from a ton of global variables to a single function in XML_RPC. For BC, the GLOBALS would be defined by calling the function. The current version of PEAR would work with the new version of XML_RPC, but since PEAR isn't officially dependent on XML_RPC, upgrading PEAR without upgrading XML_RPC would cause an error.

I will be happy to add the dependency to pear-Package.xml in cvs, for the next release. Please post this as a bug at bugs.php.net (PEAR package depends on XML_RPC but doesn't list it in package.xml)

Even though this is a specific case, I'm just as interested in the general approach. 1) How is "one-way" backwards compatibility handled in PEAR? 2) In a case where one package relies on another package to provide extended (i.e. not critical to the overall operation of the package) functionality, should it be registered as a dependency, even though it isn't entirely dependent?

si senor: <dep type="pkg" rel="has" optional="yes">XML_RPC</dep> Greg