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
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
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
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
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
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
