It is not possible to support more than one version of the same standard in an instance.

[joanma747]

In the old days the version and the standard name was in the URL of the request:
www.server.com/maps.cgi?server=WMS&version=1.0...
for a server receiving a request it was easy to know the version of the server. It was even possible have a maps.cgi capable to deal with deal with more that one version.

First: In the web API it is impossible to declare support to more that one version that are incompatible because there is only one \conformace

Second: When I get a www.server.com/collections/roads/maps as a server I only have the request and I need to respond. But do not get any info the server supposed "structure" or the existence of a swagger document or versions or nothing. So how on Earth can I know this is a OGC Maps API request 1.0? I have no information about the existence of any template. Nothing.
Ok, as a server implementor I could to assume things: I could only support one version and assume the consequences. Then I'll look on my list of URI templates and I'll try to match the URL with a URI template and if I succeed, then I will know that this is a "maps" request to a "collection" called "roads". I do not think it is possible if the server tries to support two versions because the same URL could mean different thinks depending on the version.

[aaime]

Version nummber could be put in the path, before the landing page, e.g.:
.../myservice/1.0/api, .../myservice/1.0/conformance and so on.

However... there is a catch. With OpenAPI one can have multiple services implemented in the same path hierarchy (e..g, coverages, maps and features all offered from the same root). The services will evolve over time, and eventually come to have different version numbers at different times, what if someone wants to have multiple services in the same root, but implementing each a different version? Then putting the version number before the landing page does not work anymore.

[Schpidi]

Not sure that we need the version in the path. I guess implementations or better instantiations want to version their implementation which would likely be in the path. What about having versions in responses only? /api would need to tell which versions are supported for which resources and also /conformance and all subpaths would need to report versions.

[cmheazel]

Resolution: Conclusion from the hackathon is that the conformance class identifiers listed in /conformance should include the version. The API advertises what versions it supports. The client then selects the supported version they want to use.