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
