-
Notifications
You must be signed in to change notification settings - Fork 353
Structure of the solution starting from SDK 5.0
With the introduction of SDK 5.0, we have deeply restructured the source code repositories. In SDK 4.0, the source for the SDK was spread out over multiple repo's and branches:
- In the main repo (this one): a branch for every release of FHIR (
develop-stu3
,develop-r4
,develop-r5
, etcetera). - A "common" repo (https://github.com/FirelyTeam/firely-net-common) that contained the code shared amongst those branches.
Submitting a PR most of the time meant submitting a PR for common and one for each of the release branches. On our side, merging, unit testing, building these branches became more and more time-consuming. With the advent of R4B and R6 on the horizon, this situation became unmaintainable.
Why did these branches exist in the first place? Obviously, the generated POCO's for each FHIR release were different, and so all code depending on these POCO's (for the SDK, these are mostly the datatypes and conformance resources) had to have their own copies in their own branches. This was clearly necessary for DSTU1, DSTU2 and STU3, but as time progressed, the differences between the POCOs (and especially the more mature ones like the datatypes and conformance resources) became minimal, leading to the introduction of the "common" repo, which made it possible to have some of the common code separated off.
The introduction of the "common" repo also helped us shape our thinking around how far we could share resource POCOs across versions, even when there were minimal differences between them (e.g. Meta.profile
changed from uri
to canonical
between STU3 and R4). For SDK 5.0 we have used this experience to introduce many more classes to the "common" parts of the SDK. In fact so many, that we were able to remove large swathes of code duplicated over R3/R4/R5 and we were able to completely restrucure the repository.