Re: [RFC2] Handling Backwards Compatibility in PEAR

From: 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

« previous php.pear.dev (#21851) next »