Stream: committers
Topic: Maintaining old IGs
Lloyd McKenzie (Jul 08 2018 at 23:46):
We've made a conscious decision that we will not maintain older versions of FHIR. We make technical corrections in the cae of urgent security issues, but beyond that, if something is broken in an old release, it stays broken and gets addressed in the next "official" version of the spec. Do we have the same policy for IGs, or would we consider going back and correcting old versions (e.g. of U.S. Core) instead of just fixing things in the next draft? (This has implications for how we handle the identification of "version" in Jira - if we only fix things in the current version, then I can "fix" the declared issue version, because people can only raise issues about the current release. That's what I do for core. However, if issues can be raised and addressed in old releases, then I need to allow version to be asserted, though I might default to the current version.
Grahame Grieve (Jul 09 2018 at 07:21):
I don't see how can we make substantiative changes to past versions?
Lloyd McKenzie (Jul 09 2018 at 07:54):
Not necessarily substantive changes. But technical corrections could be possible. It's hugely onerous to do for the core spec. But it wouldn't necessarily be as painful for an IG.
John Moehrke (Jul 09 2018 at 12:59):
I say current only.... Move forward or get out of the way.. :-)
Paul Knapp (Jul 09 2018 at 13:02):
Well nice if you can get it, but the US and perhaps others like to declare specific versions in regulation which means that technical corrections at least may make substantive changes to versions other than the current.
John Moehrke (Jul 09 2018 at 13:09):
That problem tends to happen when regulators don't wait for NORMATIVE... thus a self-inflicted wound. We need to get back to proper governance that recognizes "Trial Use" is different from "Normative"; that there is risk to using "Trial Use" that needs to be recognized and managed, and that "Normative" means no breaking changes without explicit identification (by named option, or versioning, or new IG).
John Moehrke (Jul 09 2018 at 13:10):
we are a standards organization here in HL7... we should act like one
Grahame Grieve (Jul 09 2018 at 22:15):
I don't understand what it would mean to make substantiative technical corrections to past versions. what do you claim to conform to?
Grahame Grieve (Jul 09 2018 at 22:15):
@John Moehrke it seems that you mean 'we should dictate to governments...'?
Lloyd McKenzie (Jul 09 2018 at 22:20):
The simplest situation would be to support non-substantive corrections or supplements that provide improved guidance without changing the technical expectations. I'm not suggesting that substantive changes would be permitted. And I'm not advocating to allow changes at all - I'm just raising the question.
John Moehrke (Jul 09 2018 at 22:24):
@Grahame No, I am saying that HL7 should act like a standards organization that it is. We should follow our governance. STU governance allows for breaking changes. Any external use of STU takes on the risk associated with STU. That is true of government not listening to us and including STU in regulation, or a 2 person company choosing to develop an app on a STU. Will it happen, most surely it will. But enabling it to happen is very different than sticking with SDO stated governance.
Grahame Grieve (Jul 09 2018 at 22:47):
well, now I'm confused about what we are talking about. We've already issued technical corrections to an IG like we made to FHIR itself
Last updated: Apr 12 2022 at 19:14 UTC
