Re: [RFC2] Handling Backwards Compatibility in PEAR

From: Date: Sat, 20 Sep 2003 16:47:47 +0000
Subject: Re: [RFC2] Handling Backwards Compatibility in PEAR
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-21849@lists.php.net to get a copy of this message
On 20 Sep 2003 at 18:38, Jan Schneider 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". > > 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. Refering to my last post *g* I would like to underline what Jan said. You can't judge "okay, I had package Foo on this server and Foo will remain functional". There are various rare cases which you cannot test all in a big app. And if you installed the "latest" package Foo and your app breaks because latest is now 2.0 and not 1.9 or so this is a bad thing in my eyes. Only conclusion I could draw from this is package all packages "statically" into the tarball - and that's not what we're looking for. Why not release a Foo2 instead of Foo 2.x? Then all problems would be solved. PS: Now I see that I got Alexey and Greg completely right ... Stefan

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