Re: [RFC2] Handling Backwards Compatibility in PEAR
| From: | Tomas V.V.Cox | Date: | Sat, 20 Sep 2003 19:43:24 +0000 |
| Subject: | Re: [RFC2] Handling Backwards Compatibility in PEAR | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-21851@lists.php.net to get a copy of this message | ||
Saturday, September 20, 2003, 6:38:23 PM, you wrote:
> Zitat von Greg Beaver <greg@chiaraquartet.net>:
>> Foo 1.1.0 feature additions
>> Foo 2.0.0 minor BC breakage - the package is essentially the same, users
>> must do text search-and-replace for a few methods
> And the conclusion of this is:
> You don't know what api you have if you do "require Foo.php".
There are ideas to add an apiVersion() method for our CS. You can also
use the PEAR base class to get the version of a package.
> I guess we'll bundle the PEAR packages we rely on with out tarballs, as many
> other developers already do with their applications. And they probably have
> a good reason for this. Let's drop the whole PEAR installer and let people
> download the packages manually from pear.php.net, this seems to be the only
> solutions that will actually work. Sad but true.
What's the sad thing? If I code a big application that relay on
certain PEAR libs I'd ship those with my app. That's what most
comercial apps does, there is only a space waste issue.
The PEAR installer can even help you here. You can have configuration
files for users, applications, hosts, etc. With them you can easily
manage the packages your application may need, preserving for example
your common PEAR installation.
--
Tomas mailto:cox@idecnet.com