[openstreetmap/openstreetmap-website] Supporting multiple API versions (#2353)

Andy Allan notifications at github.com
Fri Aug 30 10:05:45 UTC 2019

> adds work to consumers of the API

*existing* consumers of the API. Some of these headaches and quirks need to be solved by every API consumer, and the total number of future API consumers yet to be written vastly exceeds the ones written so far. So the sooner we fix them, the better, and it's a shame they've been known about and unfixed for so long already.

> Isn't there anything more compelling to do that would give API consumers more of an incentive to move to the latest and greatest version?

Maybe we will want to put some of the more compelling things in v0.8, or v0.9, or something. But I'm determined to avoid getting into the same situation as has happened over, and over, and over again, where the scope of v0.7 expands inexorably until it collapses under its own weight! I'd rather break up the logjam and work on smaller, more frequent improvements (e.g. every 18-36 months, rather than 10+ years and counting) to the API. And I'd rather keep the API changes small so that a developer can upgrade their app with a small amount of code changes that's feasible in a weekend of hacking, rather than some significant API upgrade that puts them off doing any of it and leaves them stuck on v0.6. And making life easier for the developers is the whole point of adding multiple version support, so that they can upgrade when it suits them best.

Anyway, let's talk about this further in a future issue, since we're burying the point of this PR ("is this the best code approach to multiple version support? Can you see a better way of coding the tests?") in wider discussions. 

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20190830/fb71039b/attachment-0001.html>

More information about the rails-dev mailing list