Stream: IG creation
Topic: In-place update for an IG
Bryn Rhodes (Mar 30 2022 at 20:06):
QI-Core 4.1.1 is an errata update that we'd like to be an in-place update, rather than a new entry in the package-list. Is that possible with the IG publisher?
Grahame Grieve (Mar 30 2022 at 20:26):
it's not easily possible. why?
Bryn Rhodes (Mar 30 2022 at 21:07):
We'd like it not to be possible to reference 4.1.0, so that they have to reference the updated 4.1.1
Grahame Grieve (Mar 30 2022 at 21:20):
that's not possible. the 4.1.0 package is released and nothing will change that
Chris Moesel (Mar 30 2022 at 21:23):
The FHIR history page does not list FHIR 4.0.0 or 3.0.0 or 3.0.1. I think maybe Bryn is looking for something like that?
Grahame Grieve (Mar 30 2022 at 21:23):
maybe. that's why I'm asking. Because that's not possible for an IG
Bryn Rhodes (Mar 30 2022 at 22:21):
Yeah, that is exactly the behavior I'm looking for, but if it's not possible for an IG, then ok.
Grahame Grieve (Mar 30 2022 at 22:25):
well, FMG could approve it, and I'd have to publish it manually
Bryn Rhodes (Mar 30 2022 at 22:46):
For this IG it's probably okay, but for the CQL errata, would it be any easier?
Grahame Grieve (Mar 30 2022 at 22:53):
I'd probably have to do that one anyway
Lloyd McKenzie (Mar 31 2022 at 01:26):
It seems like something we should enable for IGs? If there's a technical correction release, then we sort of want the original to only be accessible as a zip file and the updated one to be hosted at the official location for that original release.
Lloyd McKenzie (Mar 31 2022 at 01:27):
For example, if I publish a 3.0.1 release, I'd expect it to be hosted at http://hl7.org/fhir/uv/sdc/STU3, overwriting what's there now
Grahame Grieve (Mar 31 2022 at 01:48):
that's not what we
Grahame Grieve (Mar 31 2022 at 01:48):
we've done for IGs
Grahame Grieve (Mar 31 2022 at 01:48):
FMG can decide that, I guess. We've done it for FHIR core as pointed out
John Moehrke (Mar 31 2022 at 12:46):
The idea that there is some age of a previous version for which it gets converted to a zip only is an interesting concept to me. Continuing to make historic versions available is important, making them browseable and deep-linkable is more troubling.
John Moehrke (Mar 31 2022 at 12:48):
is this not (for IGs) just a case of removing all but the zips, and dropping in a simplistic index.html that just indicates the zips? Might be nice to give notice in the history.html.
Grahame Grieve (Mar 31 2022 at 19:57):
there always is notice in history.html
Lloyd McKenzie (Mar 31 2022 at 21:00):
Sure. As there should be
Gino Canessa (Mar 31 2022 at 21:10):
As an aside, I would vote for staying in line with the general NPM practices.. once a package is published publicly, you can deprecate it but you cannot remove it.
I know it was confusing to me when one day my local everything started choking because '4.0.0' no longer existed. Took a fair bit of time to figure out what actually happened.
Grahame Grieve (Mar 31 2022 at 22:34):
I have no way to remove packages
Lloyd McKenzie (Apr 01 2022 at 01:45):
Don't care about removing packages, just what shows up when you go to the URL of a specific version that's undergone technical correction.
Last updated: Apr 12 2022 at 19:14 UTC
