backwards compatibility
| From: | Marshall Roch | Date: | Fri, 22 Aug 2003 20:31:24 +0000 |
| Subject: | backwards compatibility | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-20417@lists.php.net to get a copy of this message | ||
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 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.
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?
--
Marshall Roch