Stream: implementers
Topic: Profile version or Package version
Alexander Henket (Feb 10 2021 at 10:02):
We are re-envisioning our versioning strategy. While looking for best practices we noticed that there seem to be different strategies for versioning a profile (and other package contents).
- Package has a version and each constituent has a version. Whenever you update a profile you update its version taking semver into account. The package version is updated according to the most impact of its constituents, i.e. if some major version is updated, then the package major goes up, else if minor ... else patch ... This is what we do today
- Package version determines version of all of its constituents. If package version is 4.0.0 then every profile/value set etc has that version too. This is what we learned Germany does and at least one major vendor. They have this scripted and a feature request for Simplifier is considered
** I don't think the IG Generator has a feature for it so my guess is that any IG/package that comes though that route does not enforce package version on contents, unless it is scripted otherwise. So Argonaut, us-core, IHE, DaVinci ... etc.
Without going into the pros/cons I see: is there any (most) common best practice, and what were the reasons for choosing that for your realm? @Alexander Zautke @Lloyd McKenzie @Jens Villadsen @Jose Costa Teixeira
Jose Costa Teixeira (Feb 10 2021 at 10:33):
Personally, I have no experience yet.
Reading your 1st option, I think it relies on an entire chain where each link follows the same rules for updating (which may be hard to enforce). If some minor component decides to do a major release (because of internal release schedules), would everyone downstream need to update its major number?
Alexander Henket (Feb 10 2021 at 14:44):
No. In option 1 only a particular components major version would be updated and the package that publishes it would also get a new major. Everything else stays the same.
Information standards that depend on the previous package version would continue to work for eternity until they decide to update/upgrade to the newer package version which happens to have a new major version. They would then assess impact of that package for them, which may turn out to be zero. That assessment is input for the new version of the updated information standard (patch, minor or major)
In practice a few other things are at play:
- You expect the package to be a unity so if you update a component, it affects the whole
- You would not release a new major version for the package for 1 changed resource unless you are forced into it. You would combine a couple of critical changes making the new version worth your while
- Information standards building on the same central package more often than sometimes end up being implemented by the same systems. It is not always in our best combined interest to keep one information standard stable at package 1.0.0 and another at package 2.0.0. They expect information standards to more or less move in sync or rather closely aligned at least.
Alexander Zautke (Feb 10 2021 at 16:16):
Speaking for the following German national profiles (https://simplifier.net/organization/koordinationsstellemii/~projects), we so far always had the situation where we aggregated changes into a new package release as there were content-related changes (not technical corrections) in multiple profiles. Therefore it corresponded to the version number of the package. Patch-versions for technical corrections are not reflected in the version number as we frequently release these kind of package updates (almost monthly) and the maintenance burden to increase and check the version number is too high. Additionally, these updates should be backwards compatible.
Alexander Zautke (Feb 10 2021 at 16:19):
I can understand the point that if only a single profile changes, it would not be necessary to bump the version number of all profiles. For now we only did this for consistency reasons. Don't know if this is the best practice, just saying that we handled it so far in this way.
Last updated: Apr 12 2022 at 19:14 UTC
