Stream: committers
Topic: Implementation Guide Questions
Grahame Grieve (Sep 26 2016 at 19:16):
I am working on the Implementation Guide version support. I am considering adding support for producing IGs for 1.0.2 (though it may be that we don't support code systems)
Grahame Grieve (Sep 26 2016 at 19:16):
please let me know if you think that would be good
Grahame Grieve (Sep 26 2016 at 19:16):
the other question is about 1.6.0 - I'm planning to orphan that version, and not support it any more as for today
Grahame Grieve (Sep 26 2016 at 19:16):
let me know if you think that's a mistake
Lloyd McKenzie (Sep 26 2016 at 20:24):
I would be very disappointed to lose 1.6.0 support. I can sort of understand orphaning it once 3.0 is out and published, but at least once that's done, presumably future versions will allow conversion to 3.0 and if 1.6.0 to 3.0 conversion exists, that provides a hypothetical path for 1.6.0 to 3.x support.
Grahame Grieve (Sep 27 2016 at 15:26):
why? Who's using it? maintainig 1.6.0 support means yet another conversion for me to maintain. I'll do it if I have to, but it's work, and I'm not doing it just for the sake of it.
Grahame Grieve (Sep 27 2016 at 15:27):
do you have a client who'll put $$ on the table to support 1.6.0?
Grahame Grieve (Sep 27 2016 at 15:28):
and note that my question is specific to producing implementatino guides
Eric Haas (Sep 27 2016 at 19:30):
What are the practical issues. I can still publish an IG using an old existing IG publisher for ver 1.6.0 or I can update the resources to v 1.7.0 or STU3 or whatever it will be and use the current IG publisher, right?
Lloyd McKenzie (Sep 28 2016 at 00:51):
@Grahame Grieve If you need me to do the updates to keep the 1.6.0 IG support, I'm willing to do that.
Grahame Grieve (Sep 28 2016 at 04:15):
it's not so easy, because I have to upgrade the convertor when I upgrade everything else.
Lloyd McKenzie (Sep 28 2016 at 20:25):
Can you comment it out and I can put it back in when it's fixed?
Grahame Grieve (Sep 29 2016 at 02:38):
well, maybe. But I've been counting the cost more widely, and I've realised that's only the start of it.
Grahame Grieve (Sep 29 2016 at 02:38):
you haven't indicated a specific need. And I'm not signing up to support every releases for ever. Not at all.
Grahame Grieve (Sep 29 2016 at 02:39):
because I need to run a terminology server for every release, if we're going to get it right
Bryn Rhodes (Sep 29 2016 at 16:50):
The problem with 1.7 is it's a moving target. 1.6 gives a stable basis for the IGs I'm currently working on. So I'd like to see support for it, but I don't think that means we need to support building a 1.6 IG with 1.7 tooling, or convert between resources, I just need to continue to be able to build the 1.6 IGs. As long as that's still possible, I'm fine with discontinuing support for 1.6 in the 1.7 branch (and altogether once 3.0 is published).
Grahame Grieve (Sep 29 2016 at 16:53):
so you will continue to be able to build a 1.6 guide with the 1.6 IG publisher ... for about 1 week more
Grahame Grieve (Sep 29 2016 at 16:53):
or maybe less
Bryn Rhodes (Sep 29 2016 at 16:55):
Then the existing tooling will break? Is that because there won't be a 1.6 terminology server to support it?
Grahame Grieve (Sep 29 2016 at 17:00):
yup. I'm about to make all the header changes so that everyone can stabilise their STU3 tooling
Bryn Rhodes (Sep 29 2016 at 17:03):
Okay, I'll just keep the guides up-to-date as changes happen in 1.7 then. The real kicker is that I have executable code in them and I can't execute on 1.7 until I get updated reference implementations from HAPI, so I'm pretty much stuck on 1.6, at least for the computable content.
Grahame Grieve (Sep 29 2016 at 17:07):
@James Agnew versioning is getting harder since everyone wants all this cross-version support. What options are there for someone who wants to keep their HAPI up to date?
James Agnew (Sep 29 2016 at 17:09):
Hmm. Practically what does this mean? Like people want to have a version of HAPI with the very latest definitions? Or easier access to stable versions? Or both?
Bryn Rhodes (Sep 29 2016 at 17:11):
To be clear, I don't want cross-version support, I just want access to stable versions. I'm happy to upgrade the content as it changes, but with the computable content, I can't do that until I have a version of HAPI that supports the new version.
Grahame Grieve (Sep 29 2016 at 17:12):
well, in this case, the latest version is really the question. I don't think you want to release a HAPI branch everytime someone commits to the build
Bryn Rhodes (Sep 29 2016 at 17:12):
I think for my case, the lag would be acceptable (so the guide would be published as 1.7, and use 1.7 conformance resources), but the CQL content would reference 1.6 until the engines could be updated to run 1.7.
James Agnew (Sep 29 2016 at 17:14):
So HAPI is currently at FHIR 1.6.0. Is the issue here that you want changes that exist in FHIR beyond 1.6.0?
Grahame Grieve (Sep 29 2016 at 17:16):
yes. right now, there's 1 change. But there's about to be heaps
Grahame Grieve (Sep 29 2016 at 17:16):
this is really editorial process support
Grahame Grieve (Sep 29 2016 at 17:16):
more of us are getting HAPI code in stuff around the build (not the build itself)
James Agnew (Sep 29 2016 at 17:19):
And these are meaningful changes to data model stuff that's expected to land in STU3 final? If that's the case it's probably time for a fresh sync of the model into HAPI...
It's not really a huge burden to do that- I typically push snapshot builds at regular intervals for the bleeding edge stuff in FHIR and try to tag final versions occasionaly (and especially when there's a FHIR release). I don't... think...? there is much value in holding on to the 1.6.0 release of FHIR in HAPI beyond a single release (which was HAPI 2.0)
Eric Haas (Sep 29 2016 at 17:19):
What I am hearing is that we will need to update all our IGs from v 1.6 to 1.7. But I don't know what that means on my end besides changing the version in the SDs and any updates in resources from 1.6 to 1.7
James Agnew (Sep 29 2016 at 17:20):
I've actually already synced to the latest validator (did that 2 days ago), just need to do the model and conformance files
Grahame Grieve (Sep 29 2016 at 17:21):
well, we're about to have a long stream of changes from tasks. Bryn and I are working over the metadata section of all the conforamnce and knowledge resoruces for consistency - that will be the most obvious change. But I'm also making what will be a painful structural change to valueset
James Agnew (Sep 29 2016 at 17:26):
oh boy :)
So, I certainly don't mind to make a push to keep a snapshot of this stuff current over the next while as you do this.
If we need even more realtime than that I could publish instructions for people to manually build their own local copy with more up-to-date definitions but I feel like that would be a lot of work for people with low value.
Bryn Rhodes (Sep 29 2016 at 17:46):
Yeah, I agree a local copy/manual build would be a lot of work, I don't see that as necessary for my use case at least. I'm happy with the lag, and if it's not too much work, that sounds like a good approach to just keep things refreshed after major/structural changes.
Grahame Grieve (Sep 29 2016 at 17:47):
ok I'll let James know when I think a useful clone point will be based on the editorial process
Grahame Grieve (Sep 29 2016 at 17:53):
on a related subject, I'm making a new rule: irrespective of what is published in the specification, any IGs based on past versions will use the very latest definitions of the v2 and v3 tables
James Agnew (Sep 29 2016 at 18:23):
cool cool
Lloyd McKenzie (Sep 29 2016 at 22:46):
Grahame reminded me that I'm using 1.4, not 1.6, so I'm fine with there not being a conversion process for 1.6
Grahame Grieve (Sep 29 2016 at 22:52):
yes I'm not proposing to remove 1.4 support
Paul Knapp (Oct 03 2016 at 12:04):
@Grahame Grieve by "any IGs based on past versions will use the very latest definitions of the v2 and v3 tables" do you mean just NEW IGs?
Grahame Grieve (Oct 03 2016 at 12:15):
well, IGs, when they are built, will be built using the latest versions of v2 and v3 terminology, irrespective of their FHIR version
Grahame Grieve (Oct 03 2016 at 12:15):
I'm not sure what you mean by "NEW IGS"
Last updated: Apr 12 2022 at 19:14 UTC
