<p>I still very much disagree with the overall approach to tightly couple the OSM XML version returned by the API version to the version number that is part of the URL. I found <a href="https://www.mnot.net/blog/2012/12/04/api-evolution.html" rel="nofollow">this blog post</a> raises a valid point here:</p>
<p><em>Another conversation that I have sometimes is about how to relate format changes to API versions. In short, they should be completely separate; formats can have lives of their own, and to get the most value out of them, they should do so. It’s fine to say “Version 2 of the API requires the foo resource to support version 5 of the bar format,” of course.</em></p>
<p>Let's be fair, changing the osm version header from 0.6 to 0.7 would cause some breakage for no good reason, where in reality you're maybe only trying to change the HTTP response codes or produce some nice error messages to be returned by the API. In both cases there's no valid reason at all to also change the OSM XML version number.</p>
<p>I still haven't seen an answer to a point I raised earlier on, how the long term evolution of new version numbers should look like, in particular, for how long old versions will be supported. Without a clear strategy in place, you would keep on adding more and more versions over time, to accommodate for API consumers unable or unwilling to move to a newer version. Today, they don't think about "sunsetting" a version, but in the future they will have to, and they need to be aware of that up front.</p>
<p>Handling multiple versions in parallel will add some mental strain when working with the code, even when  they share a large part of the same code base. Please keep that in mind so the additional complexity won't kill the code in the long run.</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=AAK2OLIU2CXY64D25K4GZ7LQPQZEVA5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYHJ2Q#issuecomment-544240874">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLLZZ7G4COJUJZEWQA3QPQZEVANCNFSM4IOIASAQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AAK2OLL2SRM36TM4SUQT3L3QPQZEVA5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYHJ2Q.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=AAK2OLIU2CXY64D25K4GZ7LQPQZEVA5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYHJ2Q#issuecomment-544240874",
"url": "https://github.com/openstreetmap/openstreetmap-website/pull/2353?email_source=notifications\u0026email_token=AAK2OLIU2CXY64D25K4GZ7LQPQZEVA5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYHJ2Q#issuecomment-544240874",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>