Or better yet, API versioning!
On 4/11/09, 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 >> >> > >> > -- -- Aaron Brazell web:: www.technosailor.com phone:: 410-608-6620 skype:: technosailor twitter:: @technosailor
