DSTU3 client not backwards compatible within same version

[ryankelley]

We have a system that connects to multiple FHIR implementations, so we maintain multiple clients across major FHIR releases (2/3/4). Recently we had integration partners update their server side to reference the 3.0.2 specification. Upon updating the client library to the latest version, our implementations on 3.0.1 break. This appears to be due to the version check in the FhirClient class:

if (!conf.FhirVersion.StartsWith(ModelInfo.Version))
{
    throw Error.NotSupported("This client support FHIR version {0}, but the server uses version {1}".FormatWith(ModelInfo.Version, conf.FhirVersion));
}

which references: https://github.com/FirelyTeam/fhir-net-api/blob/develop-1.x/stu3/src/Hl7.Fhir.Core/Model/Generated/Template-ModelInfo.cs#L176

public static string Version
{
    get { return "3.0.2"; }
}

It looks like the version check is hard coded based on the generated file. Should this break? Shouldn't this be a backward compatible version check within patch level releases?

[ewoutkramer]

That's a problem. Even 3.1 should probably work. Will fix this in 1.7.

[brianpos]

I would have thought would only check major/minor versions and leave the 3rd digit alone.

[ewoutkramer]

@mmsmits PR now only accepts versions with EXACTLY the same major and minor. Due to the peculiar versioning scheme for FHIR, this seems to makes sense even though it feels counter-intuitive:

• The DSTU2 sequence started with 0.4.0 and the last DSTU2 version was 1.0.2
• The STU3 sequence started with 1.1.0 and lasted through 3.0.2
• The R4 sequence started with 3.2.0 and went on to 4.0.1
• The R5 sequence started at 4.2

As we can see, even the minor versions don't give us a clue about compatibility, as 4.0 is R4 and 4.2 is R5, hence the best thing we can do is what Marten did here.

Note that we are not even trying to be smart about whether an older client should be able to talk to a newer server or vice versa.