Re: [RFC2] Handling Backwards Compatibility in PEAR
| From: | Stefan Neufeind | 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