Re: Breaking BC / Changing API / Deprecating

On 7/19/05, Joe Stump <joe@joestump.net> wrote: > > > > 3) Foo_Bar2 will be a different class thus it does not break BC. > > Oh please! If I have a major application that relies on Foo_Bar, but > want to use Foo_Bar2 because it has some new features I like I have > to change *every* require and call to Foo_Bar to Foo_Bar2. If that's > not a BC I don't know what is. > Let's say it again. MAJOR PACKAGE VERSIONS BREAK BC. Not only do you have to change the class name, you have to change your calls to work with the new version. Major versions break BC. > > > > > 4) http://pear.php.net/pepr/pepr-proposal-show.php?id=65 > > > > Arnaud. > > > > Joe Stump wrote: > > > > > >> OK, then someone answer a few things the RFC doesn't address. > >> > >> 1.) If a package has a 0.2 stable release, but no stable release > >> over 1.0 can I break BC and make API changes? According to the > >> RFC I can break BC within 0.*.* series and, since the package's > >> 1.0.1beta was never stable this rule should still apply (btw, I'm > >> talking about Net_Curl). As no stable 1.0.0 release was ever made > >> should I not be able to break BC and/or change the API? If I > >> don't break the API, but merely deprecate the stuff and it still > >> behaves as normal then there shouldn't be any issues. > >> > >> 2.) If a package goes from Foo_Bar to Foo_Bar2 how long must > >> Foo_Bar be maintained? > >> > >> 3.) Are classes in Foo_Bar2 still just Foo_Bar or are they > >> Foo_Bar2? If they are Foo_Bar2 then how does this not break BC? > >> > >> 4.) Where is the document mentioned in the RFC referred to as > >> "major package naming document". > >> > >> --Joe > >> > > > > > > > > -- Justin Patrin