Re: Breaking BC / Changing API / Deprecating

Joe Stump 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. The whole idea is that you don't release Foo_Bar2 to add a new features, you can still add all the additional apis you want. Think of Foo_Bar2 as gtk2 sure every gtk1 app wanted the new features but the whole point of gtk2 was to change the api and how the basics of everything work.

You should be able to make any change without an existing well thought out api (you can add all the new methods and even classes you want). You only make Foo_Bar when you need to restructure the api and can't leave the old one in place. I see the major use for this in, changing the entire approach to a package see xml rpc2 or fixing an api that should have never been marked stable in the first place. -josh

--Joe

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