Breaking BC / Changing API / Deprecating

From: Date: Tue, 19 Jul 2005 16:30:55 +0000
Subject: Breaking BC / Changing API / Deprecating
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-38715@lists.php.net to get a copy of this message
Guys, 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?
Imagine if every time the Linux kernel API was changed Linus changed sys calls from foo() to foo2() and so forth. 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). Thoughts? --Joe

« previous php.pear.dev (#38715) next »