[twitter-dev] Re: [twitter-api-announce] A note on our API change policy
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
[twitter-dev] Re: [twitter-api-announce] A note on our API change policy
We're not strictly an Agile shop, actually, but thanks. On Mon, Apr 13, 2009 at 18:16, James Deville james.devi...@gmail.com wrote: 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
[twitter-dev] Re: [twitter-api-announce] A note on our API change policy
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
[twitter-dev] Re: [twitter-api-announce] A note on our API change policy
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
[twitter-dev] Re: [twitter-api-announce] A note on our API change policy
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 --
[twitter-dev] Re: [twitter-api-announce] A note on our API change policy
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.
