Re: [RFC] BC breakage in PEAR - how to handle it properly

On 18 Sep 2003 at 8:24, Marshall Roch wrote: > Jan Schneider wrote: > >>I really think major version increase probably should ONLY be for BC > >>breakage, otherwise it's just a huge mess that cannot be automated. > > > > Why? If the developer feels like he wants to make a clear cut with > > his rewrite, let him so. It wouldn't break anything. The proposed > > changes want to make sure that no BC breaks happen within one > > package lifetime. That doesn't mean that you are not allowed to end > > a package's lifetime if you don't break BC. > > Releasing Foo2 *would* break BC with Foo, no matter what, since PEAR > naming conventions would require Foo_Example_Class to become > Foo2_Example_Class. > > So if package Foo2 is bc with Foo, and package Bar has 10 files > (drivers?) specifically using Foo, then the Bar maintainer has to > update all of those files to specifically call Foo2 instead? Seems > like a pain... > > I don't have any solutions, but I wanted to voice the problems I see. You are right. But without changing the filenames and classnames to Foo2 there would be no possibility for a coexistance of v1 and v2 of the package, right? Maybe you use two libs where the one depends on the old version, the other on the new. Then you coudln't require_once (indirectly) both cause you would run into naming collisions. Is there no other way than Foo => Foo2 everything? Hmm - we don't have namespaces in PHP (yet) :-)) Stefan