Re: [RFC2] Handling Backwards Compatibility in PEAR
| From: | Alexey Borzov | Date: | Mon, 22 Sep 2003 15:05:12 +0000 |
| Subject: | Re: [RFC2] Handling Backwards Compatibility in PEAR | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-21899@lists.php.net to get a copy of this message | ||
Hi!
Rob Hutton wrote:
Simple examples of the need to run two API incompatable versions of the same package have been discussed on the other threads...Your point being?.. Two API incompatible versions are handled by Package/Foo.php containing class Package_Foo Package/Foo2.php containing class Package_Foo2 (An API incompatible rewrite of Package_Foo) Package/Foo.Bar.php containing class Package_Foo__Bar (or whatever) "blessed" and distributed by application vendor Bar. Package/Foo.Rob.Hutton.php containing Package_Foo__My_Preciousss created to prevent evil PEAR developers from breaking applications I just don't buy into: 1) "no API breaks allowed" bullshit 2) having a bunch of Package/1/2/3/4/5/6/7/8/Foo.php Package/8/7/6/7/9/9/9/Foo.php and the like 3) having to fix my require_once calls and class names on each upgrade, even if no BC breakage actually happened 4) having an insane counter-intuitive versioning scheme (why not Package_Foo_2003_Advanced_Server, BTW?) 5) assuming that PEAR users are morons unable to read changelogs *before* upgrading.