I second Jesse's suggestion. Having a staging server to test out API changes would help smooth out transitions (though people needs to be careful about what change they make as presumably this will run against prod database). That way your internal developers can directly push code ready for release immediately to staging instead of waiting 5 days. It'll probably also help sanity internally at Twitter. Who knows, with developers hitting the staging API before it goes out, we might even help catch a bug or two once in a while before it goes out :-)
Yu-Shan On Sat, Apr 11, 2009 at 2:21 AM, Jesse Stay <jesses...@gmail.com> wrote: > Doug, can you guys do what Facebook is doing, and release it on a beta server > somewhere beforehand so we can test it on our apps before you actually > release it to the public? A public staging server of some sort. That will > keep these surprises from happening, and we can start working out alerts to > have in place when things might break our code that go on that beta server. > Best of all, it won't ever affect the end user. Keep the releases on that > server, then the releases out to the public on a timed release schedule. It > might take a little longer to get out to the public, but you'll have a much > happier developer base and in turn a much happier end user by doing so. That > would be my number one suggestion. > > Do you guys do any tracking of Twitter itself for developers complaining > about the API? I would also think you could gain some insight from that as > well. > > @Jesse > > On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams <d...@twitter.com> wrote: > >> Twitter's development model is pragmatically agile where features enter >> the code base right alongside bug fixes. You can see this in our changelog >> [1]. What is not clear from the log is that most of the code is written just >> days before. >> >> April 8th's rapid deprecation of the since parameter/If-Modified-Since >> header (and to a lesser extent, the removal of undocumented HTTP POST access >> to accounts/verify_credentials) [5] caught a number of developers off guard. >> The criticism of this hasty change on the impact to hackers and businesses >> alike was both valid and appropriate. The results from last month's survey >> [6] lead us to believe that the use of this parameter was minimal and that >> it was safe to capture performance gains through the deprecation. In >> hindsight, our sample size was statistically insignificant because we made a >> mistake. >> >> It is apparent we need to make a change towards transparency. Openness >> demands we give developers a clear line of communication when changes are >> made that will break current functionality. While these changes are rare, >> they do happen. As a result of this week's conversation, we will give a >> minimum of 5 business days notice before we ship code that removes currently >> documented functionality. Two notable exceptions are critical security and >> performance fixes. >> >> Five days may seem short notice but it is a compromise from our standard. >> There are two major concerns we must consider when shelving code that is >> ready for deploy: >> 1) We do not write unnecessary code. Code only exists in the deploy >> pipeline for a feature or defect fix that is ready to go out the door. We >> view deployable code as an asset that should be handling requests as quickly >> as possible. >> 2) Un-merged code adds complexity. The Twitter code base is constantly >> moving. Deploying code requires merging with the master branch which grows >> in complexity as an undeployed branch sits idle. >> >> We currently use the changelog [1], @twitterapi [2], The API Announce List >> [3], and the Dev Group [4] to inform developers of changes in hopes that >> features will get used, and deprecations will be honored. I'd suggest any >> developer with a long-running application to subscribe to the low noise, >> only signal, API Announce mailing-list [3] to receive API updates as they >> are released. >> >> Lastly, lets work together. Tell me what you developers need that we are >> not currently providing. How can we better manage this communication? Which >> method of notifications work best for you? Aside from transparency with API >> changes, what else do you want to know? >> >> 1. http://apiwiki.twitter.com/REST+API+Changelog >> 2. http://twitter.com/twitterapi >> 3. http://groups.google.com/group/twitter-api-announce?hl=en >> 4. http://groups.google.com/group/twitter-development-talk >> 5. >> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/5822fbfd5ea857c6?hl=en >> 6. >> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/68f2667f4e9842aa?hl=en# >> >> Keep the bytes flying, >> Doug Williams >> Twitter API Support >> http://twitter.com/dougw >> >> >> > -- “When nothing seems to help, I go look at a stonecutter hammering away at his rock perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that blow that did it, but all that had gone before.” — Jacob Riis
