I’m using the Java version of FHIR release 0.81. A bug fix that I needed required a later version of the code. I downloaded the code (rev. 2833) from SVN and, following the directions on the FHIR build page, had no trouble recompiling all of FHIR. Since rebuilding and replacing FHIR in our application is time consuming, I have some questions concerning release management:
- Is there a published release plan and schedule for FHIR?
- Is there a mechanism for patching or updating FHIR code between releases?
Note: this question was originally asked on StackOverflow where it was (a little unfairly) ruled out of scope.
The FHIR project is a combination of a specification, and a set of source that supports it. The project life cycle is driven by the considerations that flow from this.
The trunk version of FHIR is the current development version of FHIR, what the team works on from day to day. As a matter of ongoing work, it is not stable, and there is no guarantee that it is coherent and/or correct. The trunk version of FHIR is published here: http://latest.fhir.me/
Periodically, the core editorial team that works on the specification and the code will determine that there have been enough changes and there is enough stability to publish a development release. These are published here: http://hl7.org/fhir-develop. We typically keep upcoming connectathons that intend to use a more recent version than the formal DSTU in mind when we do this. This effectively corresponds to a beta release. Change notes and release notes are prepared when this is done.
Finally, HL7 ballots FHIR through the formal standards processes. The ballot process is based on the trunk version, and is the principle driver of the project development work. Once the ballot is passed and finalised, then a branch will be created for that formal publication – so far, there has only been one, the first DSTU (draft standard for trial use), published Feb 3 2014. This is published here: http://hl7.org/fhir.
A little further information can be found in our version numbering/change tracking policy.
- We have no formal plans around when new development releases are made – this will happen periodically
- We plan to close the next ballot cycle around May/June next year (e.g. 2015), and publish the 2nd DSTU then
- Then we will start working on the full normative release, perhaps end of 2016. note that there can be no formal timeline for this, because it depends on the ballot process
A note about DSTU: from a software perspective, the 1st DSTU was a full release of working software. From a standards perspective, this is a beta release. Once a full normative standard is released, different change control policies kick in.
With regard to patching the FHIR code between releases, the reference implementations are actively maintained. The major ones (Java, C#, and pascal) are maintained in (or for) both the trunk and the DSTU branch (tagged DSTU1). We do periodic releases to them as major bugs are identified and fixed.
The DSTU branch has a history.
Specifically, with regard to the Java Reference Implementation, as of 12-Sept 2014:
- We will maintain Maven releases for both the DSTU and development releases. The dev/trunk is not published to Maven
- The original DSTU release was numbered 0.80. After a large argument about version numbering, we changed that version number to 0.0.81, and both of these are published on Maven. 0.0.81 supercedes 0.81
- The specification will change to reference the correct Maven package directly next time it is published
- A new release for the DSTU version is required now., because of a significant issue in the json represented, but there is considerable due process to releases in the DSTU branch, and the process isn’t quite finished yet.
- I will be updating the development version immediately after the Sept 2014 connectathon, including releasing a new dev version