version field for Trias about transport-apis HOT 6 OPEN

AFAIR MobiData BW wants to remove support for 1.1 in autumn. But I'm not a reliable source for this information, I can't talk for them.

Then I would not bother to somehow manage two versions in the TRIAS configuration. And even if they support it longer, I still don't see the need.

from transport-apis.

P.S. if there was a breaking change in the Trias JSON schema:
Currently a version "1.3.1" would be not possible to store.
I found no hint in the TRIAS standard that they will have only one dot in the version.

from transport-apis.

It might be valuable for a client to know that a TRIAS instance supports version 1.1 AND 1.2.

Can you give an example? I could not come up with one on my own yet.

P.S. if there was a breaking change in the Trias JSON schema:
Currently a version "1.3.1" would be not possible to store.
I found no hint in the TRIAS standard that they will have only one dot in the version.

Indeed. However as long as there is no Patch-Version available, I would not update the schema yet, as currently a configuration with two dots would be considered a wrong configuration (as there does not exist a two or more dotted version of TRIAS yet).

from transport-apis.

Can you give an example? I could not come up with one on my own yet.

Example for instances: both, MobidateBW and VVO Sachsen currently support 1.1 and 1.2. (at least a few weeks ago)

Example for usage: Server supports 1.2 and client hasn't been updated to 1.2 and wants to know if 1.1 is still supported.

from transport-apis.

Can you give an example? I could not come up with one on my own yet.

Example for instances: both, MobidateBW and VVO Sachsen currently support 1.1 and 1.2. (at least a few weeks ago)

Example for usage: Server supports 1.2 and client hasn't been updated to 1.2 and wants to know if 1.1 is still supported.

Okay maybe I wrongly phrased my question: I assume that every server that supports 1.2 also supports requests for version 1.1. (At least as a workaround when you take the 1.1 request and just set the version of the request to 1.2) as this is a minor release and should not break anything. So If your client supports all fetaures with 1.1. it should still function, if you just change the number version number in the requests to 1.2. If that is not the case, then the TRIAS standard seem to not comply to semantic versioning and we would have a need to collect the currently supported versions. Otherwise I would leave that out and just set the version to the newest version available.

from transport-apis.

I assume that every server that supports 1.2 also supports requests for version 1.1

AFAIR MobiData BW wants to remove support for 1.1 in autumn. But I'm not a reliable source for this information, I can't talk for them.

from transport-apis.