<p>I have to agree with others here. Changing the version number in the XML and PBF files will break a lot of software, including mine. This software is out there and, even if we change new versions now to accept a new version number, old version of this software will be out there for years. There is absolutely no way we can break the compatibility if it is not absolutely necessary.</p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=360803" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/gravitystorm">@gravitystorm</a> As you mentioned yourself, 0.6 has been around for a very long time, so comparing the situation to 0.5 and earlier versions doesn't make sense. When we changed from 0.5 to 0.6 OSM was much smaller. And writting an <code>osm07to06</code> program that would just change the <code>0.7</code> to <code>0.6</code> so old software can read it, that doesn't sound like a sensible solution either. Of course this would be different if the files actually contain data in a format that needs to be different to transport this data, if we had areas or so. :-)</p>
<p>I think the only way forward here is to decouple API and file format versions. And I don't see why this is a problem really. Keep the <code>0.6</code> in the API URLs as "legacy", but the next number will be <code>1</code>, <code>2</code>, etc. (has already been discussed, we only need "major" version for API versions anyway). The next version of the files can be <code>0.7</code> or anything else we like, sometimes new API versions will mean new file versions, sometimes not. Maybe API version <code>3</code> will have an extra parameter to support version <code>0.6</code> and version <code>0.7</code> files or whatever. You could even have new file versions without new API versions if that specific file format isn't created by the API at all but only available as download.</p>
<p>We might also need to think not only about file versions and API versions but versions of the (abstract) data model behind it. I am not sure myself whether they are the same or what exactly their relationship is.</p>
<p>BTW: We already have some variants of the XML file format (JOSM, Overpass, ...) and they are not really compatible so should have gotten some kind of identifier, but that's a totally different issue again.</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=AAK2OLOX7DAQ4A3UNF64GM3QQA6WXA5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECBGQUA#issuecomment-545417296">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLJ3MR3YTQCKVCMLWCLQQA6WXANCNFSM4IOIASAQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AAK2OLLI42APWSN7MJ3PG4LQQA6WXA5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECBGQUA.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=AAK2OLOX7DAQ4A3UNF64GM3QQA6WXA5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECBGQUA#issuecomment-545417296",
"url": "https://github.com/openstreetmap/openstreetmap-website/pull/2353?email_source=notifications\u0026email_token=AAK2OLOX7DAQ4A3UNF64GM3QQA6WXA5CNFSM4IOIASA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECBGQUA#issuecomment-545417296",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>