Stream: IG creation
Topic: Release cycle for https://github.com/FHIR/ig-registry
Bart Decuypere (Mar 28 2022 at 11:51):
Together with @Jose Costa Teixeira , I set up a publication procedure for HL7 Belgium/eHealth Platform. When workgroups approve changes, they can use the build environment to test those changes. But still, for release management reasons of their own software, they want to know when a new version of an IG/package will officially be published.
Now this depends on two factors: 1) when will the IG be online, and 2) when will the new version be present in the IG registry (https://github.com/FHIR/ig-registry).
For the latter, a PR must be merged by a limited set of people. Is there a "release schedule", so that the availability of a new version becomes more predictable?
In other words, I would like to be able to answer the question: "When will the package be available?" with a specific date. I don't think this is an unreasonable question from a stakeholder's point of view.
John Moehrke (Mar 28 2022 at 12:37):
Note that the other official registry (simiplifier) at https://registry.fhir.org simply needs you to publish an RSS feed on your formal publication site. This RSS feed is automatically created by the -go-publish step.
John Moehrke (Mar 28 2022 at 12:40):
your publication step not only puts your new IG onto your web site, but also this RSS feed. The RSS feed is configured using ig-registry repo package-feeds.json. Thus you only need to get your pull-request approved once; and then you are in control of updating registry.fhir.org.
Bart Decuypere (Mar 28 2022 at 13:30):
@John Moehrke Yes, you are right, we don't need it for every version, but still if we want to add a new package. It is often at those moments that our stakeholders ask for exact dates, so that they can align communication efforts, ...
John Moehrke (Mar 28 2022 at 13:31):
Just poining out that the ig-registry process is, as you point out, dependent on a very small number of humans with the authority to accept pull-requests. The simplifier based registry is, as I understand, the future solution.
Bart Decuypere (Mar 28 2022 at 13:43):
http://registry.fhir.org/submit mentions 3 options to publish. If I understood correctly, option 3 (via https://github.com/FHIR/ig-registry), is the only option if you want to host on your own site.
Our requirements force us to do so: we need the extra features offered by the IG Publisher (on top of the features that Simplifier offers), and we must publish at our own (canonical) URL.
Jose Costa Teixeira (Mar 28 2022 at 13:46):
I presume this is because the PRs to HL7's ig-registry require approval. Knowing that others will have the same requirements (publish IGs in their own URLs), is there something that could/should be done?
Jose Costa Teixeira (Mar 28 2022 at 13:47):
pinging @João Almeida @Oliver Egger @Jens Villadsen for confirmation
John Moehrke (Mar 28 2022 at 14:04):
yes the ig-registry process is a problem for me too... but the registry.fhir.org is a formal publication mechanism, this is different than just using simplifier.
John Moehrke (Mar 28 2022 at 14:05):
Bart Decuypere said:
http://registry.fhir.org/submit mentions 3 options to publish. If I understood correctly, option 3 (via https://github.com/FHIR/ig-registry), is the only option if you want to host on your own site.
Our requirements force us to do so: we need the extra features offered by the IG Publisher (on top of the features that Simplifier offers), and we must publish at our own (canonical) URL.
this page does need to be updated. @Grahame Grieve
Jens Villadsen (Mar 28 2022 at 15:02):
Could we start by defining "publication"?
Jens Villadsen (Mar 28 2022 at 15:02):
You can build an IG - also formally and host it without it being connected to a registry
Jens Villadsen (Mar 28 2022 at 15:03):
And it will still be usable to others
Jens Villadsen (Mar 28 2022 at 15:04):
@Bart Decuypere it sounds to me like you would like a transparent cycle of how often the PR's can be expected to be evaluated
Jens Villadsen (Mar 28 2022 at 15:05):
Technically, the PR could be verified to some extent using github actions, so that the last steps would be more or less formal
Jens Villadsen (Mar 28 2022 at 15:06):
So ... if the process of verifying the PR's take too much time I suggest that someone makes a PR introducing the proper inspection using Github actions
Jens Villadsen (Mar 28 2022 at 15:07):
Then some more transparency has been introduced and the amount of manual steps are minimized
Jens Villadsen (Mar 28 2022 at 15:16):
And ... If the tool was really savvy, it would create a git pacth file - ready to be submitted
Jens Villadsen (Mar 28 2022 at 15:17):
All above is doable - it is just a matter of time
Jose Costa Teixeira (Mar 28 2022 at 15:32):
@Jens Villadsen do you mean a GH action that would check the PR? Or do you mean a GH action that reminds that a PR is waiting for a while?
Jens Villadsen (Mar 28 2022 at 15:33):
the first
John Moehrke (Mar 28 2022 at 15:40):
the publication process does prepare your PR for ig-registry... the issue is that the approval of that PR requires Grahame to approve it, that sometimes takes a day or two.
Jens Villadsen (Mar 28 2022 at 15:42):
(that just pins out that its been a couple of months since my last release)
Jens Villadsen (Mar 28 2022 at 15:43):
still ... a gh action would make @Grahame Grieve 's life easier
John Moehrke (Mar 28 2022 at 15:45):
I think the point is quality-check... I am sure he knows about GH actions.
Jens Villadsen (Mar 28 2022 at 15:46):
yes he does
Jens Villadsen (Mar 28 2022 at 15:46):
my point is that a lot of people here could make the PR containing the gh action
Jens Villadsen (Mar 28 2022 at 15:56):
Jens Villadsen (Mar 28 2022 at 16:08):
or whatever language you may prefer
Grahame Grieve (Mar 28 2022 at 21:39):
going back through this thread
Grahame Grieve (Mar 28 2022 at 21:43):
- i don't know what difference a GH action would take
- it does take me a day or two to process PRs to ig-registry
- but it shouldn't matter - the only use of fhir-ig-list.json is to power the human consumed page here: http://fhir.org/guides/registry/
- the file package-feeds.json does matter for the technical release process, but you can register that in advance of any actual relaese
- It's up to @Ward Weistra to update http://registry.fhir.org/submit not me
- I believe that packages2.fhir.org crawls the feeds in package-feeds.json several times a day. packages.fhir.org does it every hour (and some tools fall back to looking on packages2.fhir.org/packages if the package is not on packages.fhir.org)
Bart Decuypere (Mar 29 2022 at 06:50):
Jens Villadsen said:
Could we start by defining "publication"?
I like this idea of a formal/documented definition of "publication": I have been wrestling for some months now, together with @Jose Costa Teixeira to setup this publication process, and it is still trial and error to know what components are essential to the process.
The fact that you can publish an IG and not add it to a registry is new to me. Does that count as a "full" publication? What features do you miss when you do not feature in a registry? Does HL7 "require" being added to the registry for full compliance?
These are all essential questions for adopters, I think...
Grahame Grieve (Mar 29 2022 at 09:11):
I don't know what those definitions are either. I don't know what a 'full publication' is/ If you don't add it to the registry, people might not find it when looking for IGs, since people do use that page, though there are many other ways to find them
Grahame Grieve (Mar 29 2022 at 09:12):
HL7 always adds anything it publishes to that registry, but is not in a position to require anyone else (even affiliates) to do so
Ward Weistra (Apr 04 2022 at 17:50):
Chiming in from the registry.fhir.org / Simplifier perspective.
@Bart Decuypere While maybe not required, I think in practice any guide/package with the intention of being publicly available should want to be published to the FHIR Package Registry (registry.fhir.org) so others in the FHIR ecosystem can actually use it (build a specification on top with Simplifier or IG publisher, install locally or to a FHIR server, etc.).
Getting in to the FHIR Package Registry means getting listed in one of the package feeds, via Simplifier, HL7 publishing process or otherwise, or adding your own feed. Getting a new feed approved to get in that file might take a day or two, as Grahame mentions, but afterwards you can publish any new package, and versions thereof, in that feed. Registered feeds are read by Simplifier and thus registry.fhir.org, multiple times per day.
So, first time adding a feed: few days, every new package (version) in there: few hours.
On top of that you might want to get your IG (version) published to the manually curated list of the FHIR Implementation Guide Registry (http://fhir.org/guides/registry/). That involves a PR to https://github.com/FHIR/ig-registry/blob/master/fhir-ig-list.json on every publication, so expected ETA of a few days again. But this is only a list for human consumption, not needed for making your guide/package available to the world and all tooling.
Some duplication of what has been said above in there, but hope it helps.
Ward Weistra (Apr 04 2022 at 17:54):
John Moehrke said:
Bart Decuypere said:
http://registry.fhir.org/submit mentions 3 options to publish. If I understood correctly, option 3 (via https://github.com/FHIR/ig-registry), is the only option if you want to host on your own site.
Our requirements force us to do so: we need the extra features offered by the IG Publisher (on top of the features that Simplifier offers), and we must publish at our own (canonical) URL.this page does need to be updated. Grahame Grieve
I've created https://jira.hl7.org/secure/RapidBoard.jspa?rapidView=48&view=detail&selectedIssue=HSCR-430 for the update. Please comment there if more is needed.
Bart Decuypere (Apr 09 2022 at 09:25):
Thanks for all comments
Ward Weistra said:
Chiming in from the registry.fhir.org / Simplifier perspective.
Thanks for the nice summary. This is really enlightening... Please add this to the Confluence documentation!
Last updated: Apr 12 2022 at 19:14 UTC
