Re: dependencies and applications
| From: | Tomas V.V.Cox | Date: | Wed, 27 Aug 2003 16:51:19 +0000 |
| Subject: | Re: dependencies and applications | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-20656@lists.php.net to get a copy of this message | ||
On Wednesday, August 20, 2003 23:16, Greg Beaver wrote:
> Hi,
> I've been grappling with some problems relating to the use of PEAR
> packages in phpDocumentor 2.0 that are stopping development dead in its
> tracks, and I'm not sure how to resolve them. We'd like to use the code
> from several packages in PEAR that are well-written and solve problems
> that have plagued version 1.0. For instance, class inheritance is a
> very complicated tree that would be handled very well with the help of a
> package like Tree. HTML_TreeMenu is useful for the web interface.
> Cache would be useful for caching parsed output, and so on. To use
> these three packages would require us first of all to depend on a
> specific version (no rel="ge"), since any upgrade to a package that
> breaks BC would break the whole application.
[..]
> Here's the problem: imagine another application is desired which depends
> on version 3.0 of Tree, and phpDocumentor depends on 2.5. Upgrading to
> 3.0 would kill phpDocumentor, and the other app won't work with 2.5.
> The user is forced to wait for an upgrade to phpDocumentor in order to
> use the other application. Instead, he or she abandons PEAR in frustration.
This problem happens is normal in the open source world. It's easy to
solve it, instead of releasing Tree version 3.0 when a major API
changes, the point is to release Tree3 version 1.0. If minor API
changes occur, you as maintainer who wanted to depend on other
package, you have to adapt the code for the few changes.
> I know PHP 4.3.3 is about to be released, but that is why it is a
> perfect time to start thinking about where PEAR is heading - will PEAR
> ever truly be a PEAR or just a PER? It's time to decide this so that
> another solution can be written for applications that co-exists with
> PEAR if not.
I agree that at the moment we're just PER. Perhaps with the channel
stuff we could "kill two birds at the same time" and support
applications, well, not only applications but "distributions".
--
Tomas V.V.Cox mailto:cox@idecnet.com