Another point. If you are fundamentally agile, you should have stories and iterations. What if you posted current breaking change stories at the start of the iteration before you started them. Assuming a 1 or 2 week iteration, we get time to comment, and you won't have to hold code back. JD
On Sat, Apr 11, 2009 at 1:19 PM, Abraham Williams <4bra...@gmail.com> wrote: > If versioning is used how long should versions be supported? A week? A > month? Lets just say a month for now. If Twitter pushes out changes every 2 > days it is possible that there would be 15 versions running at any given > time. This is an extreme example but something to think about. > > > On Sat, Apr 11, 2009 at 13:56, Alex Payne <a...@twitter.com> wrote: > >> >> Right now, every new machine we get goes immediately into production. >> Once we have enough machines that we can get ahead of that capacity >> planning, I think a "beta.api.twitter.com" is a great idea. And/or >> versioning. >> >> On Sat, Apr 11, 2009 at 11:00, Yu-Shan Fung <ambivale...@gmail.com> >> wrote: >> > 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 >> > >> >> >> >> -- >> Alex Payne - API Lead, Twitter, Inc. >> http://twitter.com/al3x >> > > > > -- > Abraham Williams | http://the.hackerconundrum.com > Hacker | http://abrah.am | http://twitter.com/abraham > Web608 | Community Evangelist | http://web608.org > This email is: [ ] blogable [x] ask first [ ] private. > Sent from Madison, Wisconsin, United States
