Stream: conformance
Topic: profile versioning
Thomas Tveit Rosenlund (Nov 21 2017 at 10:16):
There where some talk about profile versioning on the FHIR dev days 2017, specifically a BoF session that I missed, that where organized by @Marten Smits . Is there any summary from this discussion?
Grahame Grieve (Nov 21 2017 at 10:17):
yes we clearly concluded that profile versioning is hard ;-)
Grahame Grieve (Nov 21 2017 at 10:18):
we also agreed to add some new facility to the IG publisher to give more control over versioning
Thomas Tveit Rosenlund (Nov 22 2017 at 08:28):
It's hard. Hope to see some added functionality for this soon as it will bite us all sooner or later.
Marten Smits (Nov 22 2017 at 09:50):
Hi @Thomas Tveit Rosenlund , we talked about always adding the major version to the URL, but that doesn't solve the problem that all the profiles that reference the updated one, have to change their URL as well. We have discussed solutions and for example to put version control outside of the StructureDefinition like for example Microsoft does with Nuget and most other package managers do as well, but we haven't worked that out yet. I think that it is actually pretty urgent topic, and needs to be discussed further soon.
John Moehrke (Nov 22 2017 at 13:48):
There is an infinite number of URI, so if you revise your profile in a breaking way, give it a new URI... It is either the same profile as it always has been, or it is a new one. Why is this hard? Meaning, why is it hard to not use the mechanism we have today. Why must two vectors be needed (URI + Version)? This might have been verbally described at your meeting, but could someone express it so that we can attack the problem head on?
Lloyd McKenzie (Nov 22 2017 at 18:09):
It's hard for two reasons: When you're editing, it's common to make changes, change things, back, tweak other things, etc. and when you're doing so, it's pretty unusal to be thinking consciously as you make each change "is this substantive?". And if you did, it would be a major disruption to the editing process to go through and make a URI change as soon as you've made a substantive change (and un-change the URL if you reverse the change). Second, if your profile is referenced by 40+ other profiles and those profiles are themselves referenced by other profiles, which in turn are referenced by other profiles (a situation I'm often in) a substantive change to one artifact can result in changing the URL of 100+ artifacts - with the corresponding impact on the implementer community of having to change all of those profile URLs in their systems.
Lloyd McKenzie (Nov 22 2017 at 18:10):
Having versioning driven by IG version seems to be a much cleaner mechanism to me. The IG "fixes" the meaning of all of the profile URLs within the context of that IG.
John Moehrke (Nov 22 2017 at 18:34):
That is a straw argument as you have just said, changing the URI is a disruption, yet changing the version is not a disruption. BOTH take the same cogitative effort.. Is this a major version change, a minor version change, or a sub-minor version change??? I might argue version changes are HARDER to think about. I don't disagree that it is 'nice' to show the historic flow from one to the other, but that can be done with URI too... again, there is no shortage of URI space
Lloyd McKenzie (Nov 22 2017 at 20:29):
I can change the version of everything in the IG with a flag on the publisher.
Lloyd McKenzie (Nov 22 2017 at 20:30):
Changing the URI of everything isn't possible with a simple flag because the URIs of different profiles will change in different ways.
Jens Villadsen (Nov 22 2017 at 22:36):
whether you change the version or the URI you need to notify external parties about the change when it regards anything but a maintenance (major + minor). I don't see why one of those attributes can be seen as superior to the other.
Jose Costa Teixeira (Nov 22 2017 at 22:38):
@Lloyd McKenzie a flag on the publisher?
Lloyd McKenzie (Nov 22 2017 at 23:16):
http://wiki.hl7.org/index.php?title=IG_Publisher_Documentation#Business_Version
Ewout Kramer (Nov 24 2017 at 11:00):
Yes, we've had some intense discussion on this here at Furore internally - and this has clear parrallels with how runtime resolution of symbols in things like the JVM or the .NET VM is done. We also realized this is yet another thing as references ("imports") between packages/IGs, which is not a runtime/resolution thing (what does this canonical actually resolve to?) but a distribution (design time) thing - which packages/IGs are used by my software (and which packages do these packages depend on, and so on).
Ewout Kramer (Nov 24 2017 at 11:02):
We should be looking at using an existing mechanism (e.g. maven, npm) for packaging up sets of conformance resources that need to be distributed together as a unit - and using IG as a runtime resolution mechanism to bind symbols ("canonicals") to actual structuredefinitions.
Ewout Kramer (Nov 28 2017 at 11:59):
I wrote a blog about this, hopefully summarizing our DevDays birds-of-a-feather and providing new insights & next steps!
https://thefhirplace.com/2017/11/28/versioning-and-canonical-urls/
Thomas Tveit Rosenlund (Dec 14 2017 at 12:57):
Good summary @Ewout Kramer . The only point I can think of to have some other form of the profile versioning method, other than packagring that is. Is that the definition of the information architecture, including the information models/structure tends to change at a slower pace than the code implementing the handling of that model. However, beeing able to update packages of StructureDefinitions seems like an elegant and solid solution to the versioning problem.
Last updated: Apr 12 2022 at 19:14 UTC
