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. there will always be small change. i really like to think that we (@twitterapi), and me personally, are extremely responsive and sympathetic to our developers' needs. it pains me to hear that you all think that talking to us is like talking to a brick wall -- we don't feel that's the case at all.
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. we work really hard to never remove anything (even though we really want to), but we reserve the right to add things. we have big plans for /2 -- mostly around cleaning up stuff, tightening up error codes, etc. we probably will talk about it at chirp and beyond. but, mainly, we probably won't go there until we start making non-backwards compatible changes. if there are any issues, of course, please don't hesitate to post here, or to even reach out to me directly/personally. On Fri, Apr 2, 2010 at 9:25 AM, Abraham Williams <4bra...@gmail.com> wrote: > Considering how fast Twitter changes the API I could see there being a new > version every month. If each version had a deprecation length of 4 months > and as soon as a new version was rolled out it immediately get deprecated we > would still have 4-5 versions around at any given time. That sounds like a > lot of overhead on Twitter's part. Just playing devils advocate. :-P > > Abraham > > > On Fri, Apr 2, 2010 at 09:06, Aral Balkan <aralbal...@gmail.com> wrote: > >> Hear, hear — all for locked down APIs and strict versioning. :) +1 >> >> Aral >> >> Sent from my iPhone >> >> On 2 Apr 2010, at 17:02, Isaiah Carew <isa...@me.com> wrote: >> >> >> A while back I was frustrated with an OS library method that had a well >> known quirk that never got fixed. When I cornered an engineer at a dev >> conference he told me something profound: Once an API has been released it's >> locked in. It's being used by tens of thousands of apps and millions of >> users. Changing the behavior in any way, even to improve it, is likely to >> hurt more than it helps. >> >> Last night Twitter added a new field to the search results. I use a >> publicly available JSON parser bolted on to MGTwitterEngine (both popular >> choices, I think), it had an odd trigger for detecting an early end of the >> Results dictionary and trying to fail gracefully. The new field triggered >> this condition. In other words, the lib author made a bad assumption. >> Fortunately a very easy bug to find and correct (even at 2am). >> >> However, it brings me to my point: that the search results *did* change. >> They are to spec of course, and the JSON lib *should* have been flexible. >> But it wasn't. And there was little chance of anyone finding out until it >> affected everyone using my software. For once, I was grateful that I only >> have a few thousand users. >> >> >> >> But, doesn't every change have this potential? The potential of >> triggering a well hidden bug in a client that **is** popular and be hugely >> catastrophic. Am I wrong in thinking this? >> >> >> >> To make this critique a bit more constructive I'd offer some suggestions >> of what I see in other popular API: >> 1. Every change must be opted into or deprecated away. >> 2. Deprecation periods need to last for months, not days. >> 3. Version the endpoints to allow for a one-shot way to know which >> behavior to expect. >> 4. Document the version differences in the API docs. >> 5. Add a sandbox for clients to test new endpoints or new changes in a >> safe way. >> >> >> isaiah >> <http://twitter.com/isaiah>http://twitter.com/isaiah >> >> > > > -- > Abraham Williams | Community Advocate | http://abrah.am > PoseurTech Labs | Projects | http://labs.poseurtech.com > This email is: [ ] shareable [x] ask first [ ] private. > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi