FHIR Chat · Module versioning · ibm

Stream: ibm

Topic: Module versioning

view this post on Zulip Lee Surprenant (Jan 15 2020 at 14:22):

I just opened https://github.com/IBM/FHIR/pull/592 to update all of our modules from version 4.0.0 to 4.0.1.
This includes both the modules that have changed since 4.0.0 (irregardless of the scope of change) and modules that have not changed at all.
We've also had a few discussions on how to manage module versioning going forward and we'd like to open that to the broader community.

view this post on Zulip Lee Surprenant (Jan 15 2020 at 15:42):

In the past (for our internal-only DSTU2 server), we used the following strategy:

  1. All modules in the master branch have a version of 99-SNAPSHOT

  2. At "DCUT":
    i. Decide what version number to use for the new release (say 4.0.1)
    ii. cut a release branch which has a name that matches the desired version
    iii. update all the modules to be a snapshot of this version (4.0.1-SNAPSHOT)

  3. Finally, at release time, we'd overwrite the version as part of the build and end up with 4.0.1-DATETIME

view this post on Zulip Lee Surprenant (Jan 15 2020 at 15:48):

A few things we didn't like about this for the open source project:

  • the release branches seems unnecessary and potentially even harmful because we don't want to maintain a bunch of different versions of the project. we'd like to move to more of a tag-based release process thats always moving forward along master
  • the definition of "DCUT" is not as well-defined for an open source project...the notion of when a given version is ready is a bit looser and less formal
  • it forces all modules to be updated and released in lock-step. like if want to release an important fix for just one module, we end up bumping the version number of each and every module in the release. that could be a pain for anyone using just the fhir-model or fhir-validation` modules outside of the full server
  • it leads to "sentimental versioning", where we decide "how big is the scope of all changes" wholistically, which might lead to only a patch level increase when in fact we've changed an entire module's API around. And that could get us in big trouble with users that are expecting a patch level bump not to break them

view this post on Zulip Lee Surprenant (Jan 15 2020 at 15:54):

For 4.0.0 we decided that we'd bump all the module versions to 4.0.0 and so everything became 4.0.0-SNAPSHOT in master.
For 4.0.1 we wanted to get it out immenently, so we've decided just to bump everything to 4.0.1-SNAPSHOT.
For post-4.0.1 I'd really like to explore independently versioning the modules; potentially even attempting semantic versioning at a per-module level.

view this post on Zulip Lee Surprenant (Jan 15 2020 at 15:54):

One barrier toward doing that is having a well-defined external contract for each module: https://github.com/IBM/FHIRa/issues/567
We definitely don't have that today, which means that we'd need to handle any externally-visible changes as a major version bump which I think would lead to a whole lot of major version revs.

view this post on Zulip Lee Surprenant (Jan 15 2020 at 15:56):

In the meantime, I've added an API-stable flag for each module in the repo and listed those at https://github.com/IBM/FHIR#ibm-fhir-server-module-catalog. Initially, the only module i've marked as stable is fhir-model.

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -