Re: Breaking BC / Changing API / Deprecating

Joe Stump wrote:

I've heard from the QA team that you can't break backwards compatibility without creating an entirely new package (ie. Foo_Bar - > Foo_Bar2). Or change the API without doing the same. Does this simply sound retarded to anyone else? Isn't this what version numbers are for?

This is due to the fact that you may be using multiple packages that depend on different versions of the API. As such its necessary to have a different namespace.

I've also heard that it's OK to break BC, change the API, deprecate, etc. as long as it's a major point release (ie. 1.0.0 -> 2.0.0). This makes *much* more sense, IMO. Are there any docs that outline how to go about breaking BC and changing the API in your package? I think it simply doesn't pass the sniff test to constantly be creating new packages that are exactly the same as the old ones save for a few changes in the API. Especially if care is taken to release a major point release as "alpha" and push it through to stable as other packages update themselves (or just keep relying on the older 1.x series).

If you are constantly breaking your API you are doing something wrong (tm). Also there are ways to "fix" any behaviour without breaking BC. For example you can make the new functionality optional. http://pear.php.net/group/docs/20031114-bbr.php regards, Lukas