<blockquote>
<p>I was wondering a bit how you would handle evolutionary or even revolutionary changes to the data model.</p>
</blockquote>
<p>I can sum this up with the phrase "it depends"!</p>
<ul>
<li>Different versions of the API can use different views, so if we added something to a future api (for example "node coordinate precision" or somesuch) it can be shown in the latest version and ignored in previous versions, or shown in a different way (e.g. as tags).</li>
<li>Different api versions can use different controllers too, as already demoed in this PR for the capabilities controller. This allows more subtantial changes in behaviour between api versions, and changes like fixing response codes.</li>
<li>We could use different models too. I'm not sure why we'd want to, but e.g. api/0.7/node/1 could call a node_controller that fetches data from the ShinyNewNode model.</li>
</ul>
<p>But it all really depends. I think the underlying question might be "how do we handle drastically non-backwards-compatible changes, like converting all closed ways into an area type (or if we introduce an area type into API N+1, how does that work with API N clients); or how would a change like removing segments work with two api versions running in parallel. I don't have an answer for these major structural changes, except to say that if it's logically possible at all to access the data between versions, the code approach in this PR will be able to handle it. And perhaps there'll be some change to the datastructure that prevents parallel API versions and it'll trigger a hard cutover between versions.</p>
<p>But lets not get stuck on the biggest problem, and one that's not yet in hand. In the meantime, there's a ton of backwards-compatible but needs-API-bump changes that have been stuck for years, so we can at least sort out those ones <g-emoji class="g-emoji" alias="smile" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f604.png">😄</g-emoji></p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/pull/2353?email_source=notifications&email_token=AAK2OLID2JQSKDZBDBN6ZJDQFZJW7A5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD44N3TI#issuecomment-523820493">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLNVV7BEM7VZ4LHF3WDQFZJW7ANCNFSM4IOIASAQ">mute the thread</a>.<img src="https://github.com/notifications/beacon/AAK2OLLW3KZXIBFU7VLD75DQFZJW7A5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD44N3TI.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/pull/2353?email_source=notifications\u0026email_token=AAK2OLID2JQSKDZBDBN6ZJDQFZJW7A5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD44N3TI#issuecomment-523820493",
"url": "https://github.com/openstreetmap/openstreetmap-website/pull/2353?email_source=notifications\u0026email_token=AAK2OLID2JQSKDZBDBN6ZJDQFZJW7A5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD44N3TI#issuecomment-523820493",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>