FHIR Chat · Stated version, STU3 · fmg

Stream: fmg

Topic: Stated version, STU3


view this post on Zulip Grahame Grieve (Mar 15 2017 at 00:34):

Following our stated version policy. one of the last things I do before publishing STU3 is update the major version number, and rest the minor version and revision.

view this post on Zulip Grahame Grieve (Mar 15 2017 at 00:34):

by this policy, STU3 will be 2.0.0, and revisions to it (e.g. technical corrections) would be 2.0.1 etc.

view this post on Zulip Grahame Grieve (Mar 15 2017 at 00:35):

the current build will transition to 2.1.0 as soon as anyone makes a substantiative change to it (I left this fora few weeks because it makes it a little easier to handle the forking, but it has to change once a substantiative change happens)

view this post on Zulip Grahame Grieve (Mar 15 2017 at 00:36):

there's a thread in the implementers stream proposing that instead of going to 2.0.0, we change to 3.0.0, so that the major version corresponds to the stated release (R3 = 3.0.0)

view this post on Zulip Grahame Grieve (Mar 15 2017 at 00:37):

this means we would just skip 2.x altogether.

view this post on Zulip Grahame Grieve (Mar 15 2017 at 00:37):

I think this is a good simplification, and so I'd like FMG to endorse this.

view this post on Zulip Lloyd McKenzie (Mar 15 2017 at 01:21):

+1

view this post on Zulip Lloyd McKenzie (Mar 15 2017 at 01:22):

Is there a reason we wouldn't change the build to be 3.1 as soon as we produce 3.0? Because substantive changes could happen at any time.

view this post on Zulip Grahame Grieve (Mar 15 2017 at 03:27):

if it's like last time, there was a fair bit of work settling the reference implementation and it was easier when the trunk had the same version. And there were no substantiative chansg for quite a few weeks while we all caught our breath

view this post on Zulip Lloyd McKenzie (Mar 15 2017 at 03:59):

But the reference implementations aren't referenced by the core spec anymore, so not clear why it would matter. Not saying we can't keep things frozen, just not sure we'd want to delay changes if we didn't have to

view this post on Zulip Grahame Grieve (Mar 15 2017 at 03:59):

it was just convenient, that's all

view this post on Zulip Paul Knapp (Mar 15 2017 at 09:11):

Confirmed with TSC that they no longer use release in the ballot naming, so HL7 FHIR Release 3, HL7 FHIR Release 4 - as short forms if not the full name should be fine.

view this post on Zulip John Moehrke (Mar 15 2017 at 12:19):

+1 the build version starting at 3.0.0 for STU3. I still am not comfortable with a marketing phrase that is not clear about STU.

view this post on Zulip David Hay (Mar 15 2017 at 23:58):

+1 - consistency is good...

view this post on Zulip Lloyd McKenzie (Mar 16 2017 at 00:31):

Approved on call


Last updated: Apr 12 2022 at 19:14 UTC