Re: Breaking BC / Changing API / Deprecating

Joshua Eichorn wrote:

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.

For instance, PEAR_PackageFileManager added an entirely new class, PEAR_PackageFileManager2, for handling the new package.xml 2.0 format. I simply released that as 1.6.0a1. There is no BC break because existing scripts function normally. You have to explicitly code for PEAR_PackageFileManager2 to take advantage of the new features, but old features work just as they always have. Greg