> we strive to do everything we possibly can to keep everything as backwards > compatible as possible -- in fact, we jump through many hoops to do it.
maybe it's just me, but "backwards compatible" seems like a liability rather than a benefit. attempting backwards compatibility constrains your innovation without providing any real insulation from changes to customers. > however: we will change things. backwards compatibility requires that you > all have -good- XML and JSON parsers that can accept the addition of new > parameters without breaking. agreed. and my anecdotal situation could have been resolved if my library didn't have that bug. yep. you're right. ... but you've also missed the point. the point is that as the number of users of your API grows, EVERY change you make WILL stimulate SOME bug. it just doesn't matter how careful you are, i am, or how great my libraries are. the only hope that we have of keeping those bugs from reaching real customers is to test the changes before deploying. step back for a moment. think of the user. they don't experience the API and the client and the backend as separate entities. they just see Twitter as a single whole. changes to the API are making revisions to that whole. it seems wise that we have some way to do integration testing with the other parts before letting the customer see the changes. right now, you're introducing changes to a complex system without testing their real world results on your customers. > it pains me to hear that you all think that talking to us is like talking to > a brick wall each time i post to this list you respond in this way. i'm not sure what i'm doing to provoke this feeling, but i assure you it's not what I think at all. you guys are whatever the opposite of a brick wall is. i apologize, i must have a gruff tone. i'm not angry. in fact i enjoy the back and forth that we have with the API team. but i'll see if i can't just tone it down a notch. :-P Isaiah -- To unsubscribe, reply using "remove me" as the subject.
