Investigate and Support multiple IGs versions and artifacts

[prb112]

Is your feature request related to a problem? Please describe.
Investigate and Support multiple IGs Versions and Artifacts

For instance with C4BB 1.0.0 and 1.1.0 are out and in the wild, yet clients may assert to 1.0.0, and we need to support both.

Describe the solution you'd like
We should have multiple structures in the same package in fhir-ig-carin-bb.

• ResourceProvider
• folder structure

We'd want to maintain a single .index.json file

Figure out how to set the default tagged version

Describe alternatives you've considered
Splitting the resources into separate jars. It becomes unwieldy and hard to manage.

Acceptance Criteria

1. GIVEN [a precondition]
   AND [another precondition]
   WHEN [test step]
   AND [test step]
   THEN [verification step]
   AND [verification step]

Additional context
n/a

[prb112]

1 - Enumerate Breaking changes/Differences when picking up new C4BB
2 - Determine dual version maintenance

[lmsurpre]

Relevant thread from chat.fhir.org: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.E2.9C.94.20How.20to.20handle.20Implementation.20Guide.20versions

The same OP brought it up in the c4bb stream as well: https://chat.fhir.org/#narrow/stream/204607-CARIN-IG.20for.20Blue.20Button.C2.AE/topic/CARIN.20BB.20STU1.2E1.20Published/near/245842099

[lmsurpre]

1. Make the decision on whether we package each version in its own jar or whether we combine multiple versions into the same jar.

2. Create design for how to configure which is the "server default". I.e. which version do we validate against if the resource claim conformance to the profiile but with no version.

[prb112]

Options

Only considering released versions:

Option 1: Multiple IGs in the same JAR

Pros

• Single Deliverable
• Easy to switch without redeploying

Cons

• Hard to eliminate or keep a version out of the Registry
• Extra Size and bloat

Option 2: Single IG in the Single JAR

each IG and release version becomes

Pros

• Single Deliverable
• Fit for Single IG and Purpose

Cons

• Restart/Redeploy with the latest IG

Downstream

• we'll have to update fhir-examples to consider the various versions.
• which one is the default

*** Please comment or add directly to this comment.

[lmsurpre]

With option 1, I think we'd need to come up with a naming convention to help users manage all the jars...I think I'd want both the IG version and our release version in the jar name so that we can keep the different IG version jars straight.
For example, for US Core, we might end up with two different projects:

1. fhir-ig-us-core-3.1
2. fhir-ig-us-core-4.0

And so the jars would become like:

• fhir-ig-us-core-3.1-4.10.0.jar
• fhir-ig-us-core-4.0-4.10.0.jar

Is there a better way to distinguish the IG version from the release version?

[prb112]

Q: What we should do with the technical corrections?
A: ... Hybrid approaches are fine... when we hit the technical corrections.
Let's start up with Major.Minor as individual models. (Could also consider stu3, stu4, r4)

fhir-ig-us-core-stu3 (3.1.0, 3.1.1)
fhir-ig-us-core-stu4 (4.0.0, 4.1.0)

Net: Hybrid approach?

Option 1: Multiple IG versions in a single project / jar (as long as you can exclude and set a default)

Embed the version in the package hierarchy hl7/us/core/stu3/package

[lmsurpre]

Embed the version in the package hierarchy hl7/us/core/stu3/package

The proposed path layout overlaps with the community's structure for IGs that support multiple FHIR versions: https://confluence.hl7.org/pages/viewpage.action?pageId=35718629#NPMPackageSpecification-Multi-versionsupport

I think we should use the three-number version instead to help differentiate it:

• hl7/us/core/3.0.0/package
• hl7/us/core/3.0.1/package
• hl7/us/core/3.1.0/package