Stream: R4A/B/R5 Discussion
Topic: Version
Grahame Grieve (Mar 04 2021 at 18:59):
@all A quick and now urgent question around the stated version for R4B, because I don't see that we ever formally resolved this
Vassil Peytchev (Mar 04 2021 at 19:04):
As in, will 4.6 work?
And is this about npm packaging mostly, or are there other considerations?
Grahame Grieve (Mar 04 2021 at 19:05):
we have published R4 as 4.0.0 and 4.0.1, and one could imagine a 4.0.2 coming.
We have published R5 drafts as 4.2.0, 4.4.0, and 4.5.0. This is following our current documented practice, though there is a proposal to change this so that would have called them 5.0.0-preview1, 5.0.0-preview2, and 5.0.0-preview3
So what should we do with R4B ballot #1? I see the following options:
- 4.0.5, intending to publish as 4.1.0
- 4.1.0-ballot1 (pre-adopt proposal above, though it is not even written up for FMG approval)
- 4B.0.1 - break from semver completely (what we have now is a variant on semver, constrained by HL7 publication cycles), with a final being... 4B.1.0?
- 4B.0.0-ballot1, which would be dollar each way
- 4.6, which would mean R4 versions interlace with R5 versions (next R5 ballot would be 4.7)
Grahame Grieve (Mar 04 2021 at 19:05):
it's not really about npm packaging, though whatever we choose has to be legal there, and work
David Pyke (Mar 04 2021 at 19:06):
4.0.5/4.1.0 makes the most sense to me. There are far more changes in 5 so I'd not want to make the market feel this is what to expect with R5 comes out
Catherine Hosage Norman (Mar 04 2021 at 19:06):
What does the preview number indicate?
Grahame Grieve (Mar 04 2021 at 19:08):
just the sequence of publishing previews
Grahame Grieve (Mar 04 2021 at 19:09):
the big problem with the 4.0.5/4.1.0 option is that I expect that there'll be an R5C coming at us, though that's certainly not a sure thing
Grahame Grieve (Mar 04 2021 at 19:09):
I think I prefer 4.1.0-ballot1
David Pyke (Mar 04 2021 at 19:09):
As long as we end up at 4.1.0, I think that would make the market understand what's being released.
Grahame Grieve (Mar 04 2021 at 19:10):
though 4.1.0-ballot1 doesn't solve for 4C.
Jean Duteau (Mar 04 2021 at 19:12):
I think that R4B should become 4.1.0. so 4.1.0-preview1, 4.1.0-ballot1 makes sense to me.
R4C would be 4.2.0 so 4.2.0-preview1, 4.2.0-ballot1, etc. makes sense for that.
Grahame Grieve (Mar 04 2021 at 19:12):
but we have already published 4.2.0
Jean Duteau (Mar 04 2021 at 19:13):
ah, i missed that in your initial post above. dang, we shot ourselves in our foot
David Pyke (Mar 04 2021 at 19:14):
Can we do it as 4.5.1? It is built off 4.5
Grahame Grieve (Mar 04 2021 at 19:14):
indeed. might be more significant than the foot
Grahame Grieve (Mar 04 2021 at 19:14):
4.5.1 is R5. It's not built off 4.5.0 at all
David Pyke (Mar 04 2021 at 19:15):
Right. We have shot ourselves quite badly with our versioning to date
Jean Duteau (Mar 04 2021 at 19:15):
do we have the ability to change our R5 versions? get them off the 4.x.x scheme?
David Pyke (Mar 04 2021 at 19:16):
So move R5 to 5.0-preview1 and have 4.6 be R4B?
David Pyke (Mar 04 2021 at 19:17):
That seems like it will break a bunch of things
Grahame Grieve (Mar 04 2021 at 19:18):
go back and retrospectively reversion things? scary idea
David Pyke (Mar 04 2021 at 19:18):
Maybe move R5 to 4.9.x and then have R4B be 4.something?
David Pyke (Mar 04 2021 at 19:19):
IF 4.2 becomes 4.9.2 and 4.4 becomes 4.9.4 that gives us back 4.1
David Pyke (Mar 04 2021 at 19:20):
REversioning still is scary but we're not changing the major version in that case
David Pyke (Mar 04 2021 at 19:20):
It also sets a new precedent for R5 if we need to do this again
Jean Duteau (Mar 04 2021 at 19:22):
if you're going to re-version, I would re-version properly
David Pyke (Mar 04 2021 at 19:26):
So, 5.0a1, 5.0b1, etc?
Jean Duteau (Mar 04 2021 at 19:26):
i liked Grahame's 5.0.0-preview1, 5.0.0-preview2, and 5.0.0-preview3
Bryn Rhodes (Mar 04 2021 at 19:34):
If we've already broken with semver, why not call it what we've already been calling it? 4B.0.0?
Grahame Grieve (Mar 04 2021 at 19:35):
well, we haven't broken with semver. And that'll be a problem with npm
Jean Duteau (Mar 04 2021 at 19:36):
does 5.0.0-preview1 break semver?
Grahame Grieve (Mar 04 2021 at 19:37):
no. the -xxxx is part of semver
Jean Duteau (Mar 04 2021 at 19:37):
that's what I thought
Vassil Peytchev (Mar 04 2021 at 19:38):
go back and retrospectively reversion things? scary idea
But 4.2 to 4.5 are versions that are meant to exist ephemerally, in terms of actual implementations. Is moving them to 5.0-previewN going to significantly impact tooling?
Jean Duteau (Mar 04 2021 at 19:39):
i really think we bite the bullet and unshoot ourselves (sorry for mixing metaphors):
rename the R5 preview builds to 5.0.0-previewX
reuse the 4.x.0 builds as needed
use 4.1.0 for R4B and 4.2.0 for R4C, etc.
Jean Duteau (Mar 04 2021 at 19:42):
if we're lucky, there won't be a R4C and we won't need to re-use 4.1.0
Grahame Grieve (Mar 04 2021 at 19:43):
Is moving them to 5.0-previewN going to significantly impact tooling?
No. None of the reference implementations adopted them. So it's technically possible to do that without breaking anything, I think. Just work for me to deal with it
Peter Jordan (Mar 04 2021 at 20:02):
Hate to put a spanner in the works, but there is an R5 version of the C# library https://github.com/FirelyTeam/firely-net-sdk/tree/release/3.0.0-r5 - although I'm not sure how widely implemented that is - @Brian Postlethwaite ?
Grahame Grieve (Mar 04 2021 at 20:24):
java has one too, but it will roll forward with the R5 build. So I can't simply fix 4.5.0 immediately
Rik Smithies (Mar 04 2021 at 21:19):
EMA may go live with R5 Preview 2 (4.4.0) because that is the most recent tooling available. So we don't want that to get re-versioned.
Grahame Grieve (Mar 04 2021 at 21:25):
what tooling?
Rik Smithies (Mar 04 2021 at 21:36):
The Microsoft FHIR server
Jean Duteau (Mar 04 2021 at 21:36):
i don't completely understand how changing the version number of some things would break existing implementations unless they were very dependent on the NPM packages of those versions.
Rik Smithies (Mar 04 2021 at 21:37):
We know that all sorts of problems and confusion are caused by clashing version numbers, or we wouldn't be having this thread
Jean Duteau (Mar 04 2021 at 21:39):
i get that, but no matter what we do, we're going to have confusion. It makes the most sense to me to make our go-forward path make the most sense and then determine how we can get there.
Rik Smithies (Mar 04 2021 at 21:40):
There are lots of unique strings to go at without re-using old ones.
Jean Duteau (Mar 04 2021 at 21:40):
Rik Smithies said:
There are lots of unique strings to go at without re-using old ones.
Sure, except that R4C being 4.2.0 makes the most sense.
Rik Smithies (Mar 04 2021 at 21:42):
It matters less what the sequence is, other than aesthetics. Having clashes is very bad.
Rik Smithies (Mar 04 2021 at 21:43):
No one puts the sequences into software, but the actual numbers do get implemented.
Jean Duteau (Mar 04 2021 at 21:43):
I think that there is an inherent understand of the sequence. When I tell people today that R5 is 4.2, 4.4, and 4.5, they think we don't understand how semantic versioning is supposed to work.
i think that you could, in the interim, do the following:
a) re-publish 4.5.0 as 5.0.0-preview3
b) use 5.0.0-previewX and 5.0.0-ballotX going forward
c) publish R4B as 4.1.0-preview1 and then 4.1.0-ballot1 (or just skip the preview, I suppose)
d) publish the final R4B as 4.1.0
e) leave everything else as is
This avoids the renaming problem (since we're not changing 4.5.0, just republishing with a different version number) and gets us on the right track going forward.
If an R4C comes along (which I don't see how, given the timeline for R5), then we can figure out what to do with that.
Rik Smithies (Mar 04 2021 at 21:46):
Having an ugly pattern is not good but re-issuing a version is very obviously bad practice. It is already bad that 5 is 4.x yes. I don't see 4C happening either.
Jean Duteau (Mar 04 2021 at 21:48):
I'll note that (a) could actually be "publish the next R5 preview as 5.0.0-preview4". You could also add (a.1) eventually republish 4.2, 4.4, 4.5 as 5.0.0-preview1,2,3 when we have time and resources.
Rik Smithies (Mar 04 2021 at 21:50):
why is there a need to republish things?
Rik Smithies (Mar 04 2021 at 21:51):
that will also be confusing, with two numbers for the same thing
Jean Duteau (Mar 04 2021 at 22:07):
because the current numbers are wrong according to the about-to-be-agreed-upon scheme
Grahame Grieve (Mar 04 2021 at 22:08):
about-to-be-agreed-upon scheme
Since it hasn't even got a task created for it yet, it's a bit premature to say it's about to be agreed on
Jean Duteau (Mar 04 2021 at 22:08):
i like it and you thumbed it, so that's good enough for me!
Rik Smithies (Mar 04 2021 at 22:08):
but I dont see that as a big problem and any benefit would be far outweighed by having two numbers for the same thing
Jean Duteau (Mar 04 2021 at 22:08):
you don't see it as a big problem, but I do, so...
Rik Smithies (Mar 04 2021 at 22:09):
:-) who is affected by having a not very nice pattern in an old version number that we have moved on from?
Rik Smithies (Mar 04 2021 at 22:10):
but I call something X and you call it Y, surely that is going to confuse, not just be ugly
Jean Duteau (Mar 04 2021 at 22:10):
when I teach FHIR and explain the versions, I always get "why is R5 still version 4?" and "what happened to 4.1?"
Rik Smithies (Mar 04 2021 at 22:13):
so it would be better to improve that, going forward. But not in such a way so that things actually clash, or have duplicate numbers.
Bryn Rhodes (Mar 04 2021 at 22:22):
+1 to resetting so that we don't interlace version numbers. To go from 4.1 to 4.6 with interim 4.2 and 4.5 that are really 5 is really confusing.
Bryn Rhodes (Mar 04 2021 at 22:25):
Having said that, we could just go with 4.0.2 and 4.0.3 indefinitely, on the grounds that the '4.0' bit applies to the normative aspects of the specification...
Rik Smithies (Mar 04 2021 at 22:26):
I would say that the golden rules of versioning are: Don't re-use numbers. Don't re-number things. Use a nice semantic meaningful number. In that order. #3 is important but not at the expense of 1 and 2.
Grahame Grieve (Mar 04 2021 at 22:33):
we could just go with 4.0.2 and 4.0.3
There's lots of code out there that assumes that 4.0.x and 4.0.x are compatible
Catherine Hosage Norman (Mar 04 2021 at 22:38):
Since it is preview 3, would it not be 4.5.3 ?
Jean Duteau (Mar 04 2021 at 22:59):
no, the third number is intended (in Semver) to be the patch number. So that would imply that 4.5 had three fix releases. that's different from a preview which occurs before the official release of 4.5 or 4.1 or 5.0
Richard Townley-O'Neill (Mar 04 2021 at 23:29):
Maybe
Keep R4 and R4B and R4C using 4-series numbers
Make all future R5 versions 5-series numbers
So
4.0.1, 4.0.2, are R4
4.2.0, 4.4.0, 4.5.0, 5.0.0-preview1 etc are R5
4.1.0 is kept as space for any nasty change to R4
4.6.0-preview1 is R4B
4.7.0-preview1 is for R4C
Vadim Peretokin (Mar 05 2021 at 07:23):
I agree with Rik, a reset would be disastrous.
Ward Weistra (Mar 05 2021 at 09:17):
In general I think divorcing the marketing version number (R4, R4B, R4C, R5) from the underlying software version number (1.2.3) is a good solution.
So you can keep clean semver version numbers under the hood and respect:
- Up the major version number on any breaking/not backwards compatible change
- Up de minor when major features are added, no breaking changes
- Up the patch for any back minor corrections.
Perhaps we can do that starting at R5?
Ward Weistra (Mar 05 2021 at 09:30):
For R4B we can't go lower than 4.0.3.
And to have it be some reflection of what it was build on I would want to go any higher than the first R5 release numbers (4.2.0 it seems http://build.fhir.org/history.html)
So I'd agree with Grahame go for 4.1.0-preview1 -> 4.1.0-preview2 -> 4.1.0
Should I conclude from http://build.fhir.org/history.html that 4.1.0 also already has a meaning? Or hasn't that been released?
The build version als doesn't acknowledge the existence 4.0.0 and 4.0.1, hope that will change too :thinking:
Lloyd McKenzie (Mar 05 2021 at 14:43):
The base issue is that SemVer isn't designed to support forking - which is what we're doing.
Josh Mandel (Mar 05 2021 at 15:35):
I agree with Lloyd's diagnosis, though I'd note that our proposed "forking"' structure isn't a general-case forking paradigm, because (for instance) the "fork" of R4B->R4C->... would never lead to an incompatible release. So we're discussing a kind of "partial forking" or "continued development on old releases" model. I'm not familiar with other projects or standards that work this way (are there example?)
Gino Canessa (Mar 05 2021 at 15:51):
I don't know if I agree about issues with "forking". SemVer works perfectly well for things like having a 4.1.3 branch separate from a 4.0.6 branch. Many projects do this in production for long-term security updates.
I think the biggest challenge is that we mangle the numbers with the pre-releases of the 'next' (e.g., R5 being 4.5). If R5 were using 5.x, then I don't think we'd even be having this conversation (R4B would just be 4.1.0).
It would be great if we could fix this. I agree that re-using numbers is problematic (e.g., many systems have things that specify 4.5 as R5, all of those systems would need to be updated in order not to break), so I would personally like to see something like 4.6.0 (or even a jump to something like 4.10.0). I would also move R5 out from 4.x (leave anything there as historical, just start building with the new numbers).
Josh Mandel (Mar 05 2021 at 15:52):
SemVer works perfectly well for things like having a 4.1.3 branch separate from a 4.0.6 branch
Yes, for security updates as you say. These historical release versions aren't generally used as a basis for new feature development though (in my experience anyway).
Josh Mandel (Mar 05 2021 at 15:54):
Like, I think Lloyd's right that we're trying to use semver outside of the usual paradigm -- but I'm not sure it's unworkably far outside. I'd feel better if we knew other projects doing something roughly similar.
Vassil Peytchev (Mar 05 2021 at 16:01):
Is there more to SemVer to be used for our needs than as follows:
- maj.min.x versions are always backwards compatible, basically fixes only
- maj.min versions can have breaking changes in FMM Z and lower (Z=3?4?), but backwards compatible for everything FMM Z+1 and above, no promotions to normative
- maj versions can have breaking changes, and all new normative changes.
Not sure if there are special cases to be considered for datatypes, or other infrastructure changes.
Vassil Peytchev (Mar 05 2021 at 16:07):
And I agree that forking is unrelated to this. Given that we are publishing versioned releases, I think Git-flow fits well. The only question is whether the CI infrastructure we have needs to be beefed up...
Gino Canessa (Mar 05 2021 at 16:19):
Josh Mandel said:
SemVer works perfectly well for things like having a 4.1.3 branch separate from a 4.0.6 branch
Yes, for security updates as you say. These historical release versions aren't generally used as a basis for new feature development though (in my experience anyway).
I don't think that's a failing of SemVer - if you have active development on two "forks" like that, everyone working on it needs to double their work to prevent divergence. The numbering issue is tangential to that.
I don't know of a development process that includes a method for working on two different bases at the same time, other than someone applying their changes to both branches. In the context of FHIR, this is one of the items I think needs to be addressed in the release process. What 'major' changes are causing us to even have an R5 branch yet - shouldn't we be assuming a 4.x by default?
Lloyd McKenzie (Mar 05 2021 at 16:29):
R4B isn't technically backward compatible with R4. It's just that we're only breaking things we believe no-one cares about in R4. If we do an R4C (rather than just a x.x.1 technical correction), there's no guarantee it would have full compatibility either.
Lloyd McKenzie (Mar 05 2021 at 16:44):
We're really doing a Git-ish thing where we fork and then merge things back together into a future release. I.e. R5 will end up incorporating stuff from R4B as well as the R5 development branches. In theory, R4C changes might end up getting merged into R6...
Gino Canessa (Mar 05 2021 at 16:53):
Fair enough, but I think it means it's even more important to update the release process, e.g.:
- only breaking changes in Normative or at least FMM 'x' matter for changing the major release, or
- split the release into a 'core' and an 'extended' set.
I bring it up because I don't think it is sustainable to develop in the way we're talking about here. Adding new content in multiple divergent branches will not result in a stable specification.
Lloyd McKenzie (Mar 05 2021 at 17:02):
Agree that we should explore alternatives for going forward, but that should be a separate thread
Vassil Peytchev (Mar 05 2021 at 17:02):
R4B isn't technically backward compatible with R4. It's just that we're only breaking things we believe no-one cares about in R4. If we do an R4C (rather than just a x.x.1 technical correction), there's no guarantee it would have full compatibility either.
So it fits 4.N as described, doesn't it? The incompatible changes are all at FMM-2 or lower, I think.
Gino Canessa (Mar 05 2021 at 17:17):
I'm not sure Vassil. I am having some difficulty reducing the versions page to actual rules.
- Anything with a "breaking change" is supposed to increment the major version
- In one sentence, a breaking change is anything that would make an application not compatible.
- In another, anything "Draft" or "Trial Use" (specifically including breaking changes) can change from "version to version", with no expectation of compatibility.
My current interpretation is that R4B is a minor revision (4.x.0), but also that there's no reason not to include a lot of items that were pushed "out of scope" for R4B.
Vassil Peytchev (Mar 05 2021 at 17:26):
There is a whole discussion on the distinction between breaking changes and substantive changes:
The intent of these rules is to ensure that applications that are conformant to an existing specification are also conformant to subsequent versions. In practice, there are many subtle issues around inter-version change, and the exact rules are subject to further clarification based on feedback from implementers.
I think the interpretation that non-breaking change applies to FMM Z+1 for some value of Z<5 does not contradict what is currently specified. In other words, it might be substantive but not breaking to adopt such an interpretation.
Josh Mandel (Mar 05 2021 at 18:01):
Major versions "Increments every time a breaking change is made"
and
Breaking changes are changes that mean that previously conformant applications are no longer conformant to the updated specification
... so any time we have a publication with breaking changes (irrespective of the FMM of the resources where the changes occur), that requires a major version increment. But we should be willing to do that as often as needed to support the community.
Lloyd McKenzie (Mar 05 2021 at 18:13):
And we're certainly not wanting to increment major version for R4B - but it's absolutely got breaking changes (renaming resources, restructuring resources, dropping resources, etc.)
Josh Mandel (Mar 05 2021 at 18:18):
And we're certainly not wanting to increment major version for R4B - but it's absolutely got breaking changes
Uh, that seems to violate the rules.
Lloyd McKenzie (Mar 05 2021 at 18:22):
Yup. But if we increment, then R4B gets a label of 5.0.0 and R5 becomes 6.0.0 - and that's true craziness...
Vassil Peytchev (Mar 05 2021 at 18:27):
And we're certainly not wanting to increment major version for R4B - but it's absolutely got breaking changes
Uh, that seems to violate the rules.
Not if we follow the blurb I quoted and clarify that "breaking changes" apply to certain FMM and higher. I think that is consistent with "the exact rules are subject to further clarification based on feedback from implementers". All the breaking change in R4B are things that even if they were implemented, it is fully expected that such implementation will break. We are just clarifying where major version breakage boundaries apply.
Rik Smithies (Mar 05 2021 at 18:33):
for the Medication Definition changes they were FMM level 0 before, so it could be argued that they were not even resources ...
Gino Canessa (Mar 05 2021 at 18:37):
Lloyd McKenzie said:
Yup. But if we increment, then R4B gets a label of 5.0.0 and R5 becomes 6.0.0 - and that's true craziness...
Or we get FHIR R4 v5.0, v6.0, etc. Like HL7v2 version 10.5, DICOM3 version 2021a, etc. Seems like a common thing, actually.
Lloyd McKenzie (Mar 05 2021 at 18:43):
Difference is that I don't think we're prepared to say that future versions of FHIR will all be backward compatible with R4 - and that's an expectation in the v2 and DICOM space
Josh Mandel (Mar 05 2021 at 20:37):
Gino had convinced me that this wasn't the firm expectation for DICOM (just a strong community preference -- though I may have misunderstood).
Gino Canessa (Mar 05 2021 at 21:17):
It depends on your definition of compatible.
One example from DICOM is retiring SOP Classes (typically when replaced by a newer version, e.g., a new, incompatible version of "Ultrasound data"). Once retired, future implementations aren't likely to accept/process the old one.
It doesn't grant any sort of 'magic' compatibility, but the protocol defines how nodes negotiate what is supported by each, and the definitions of those items need to remain compatible. Because of the naming conventions in FHIR, the concept doesn't map exactly. It would be as if each resource had its own versioning - servers would indicate that they support Patient v3, Patient v4, etc..
As for v2, I don't know the process for adding/changing content. But I believe version 2.8.2 has additional content over 2.2 (e.g., new messages/segments). I assume that new content is not perfect every time it is proposed, so I also assume there is some process where those changes are added, tested, and revised (and there is probably no expectation of compatibility during that process).
Right now, FHIR is developed by including those new/experimental/exploratory/under development resources in the same bucket as the Normative safe-to-use things. The current release problems are because of that, and the versioning issue is just a symptom.
Josh Mandel (Mar 05 2021 at 21:59):
retiring SOP Classes
Retirement is a good example of how to manage changes without breaking compatibility; it introduces a new feature and deprecates an old one without breaking anything. I thought you were telling me yesterday that it's also allowable in DICOM to break things, but I may have misunderstood.
Lloyd McKenzie (Mar 05 2021 at 21:59):
I think asserting that only normative is "safe to use" isn't the right description. I don't think AllergyIntolerance or Encounter have been unsafe to use. But they still could change in breaking ways. And stuff like Medication governance stuff has been completely refactored (and could end up getting refactored further). If we published R4 with only normative stuff, it would have been useless. Even with R5, certain essential things might not hit normative. (E.g. PA is nervous about locking down Practitioner)
Gino Canessa (Mar 05 2021 at 22:20):
Josh, I apologize for any confusion. Retirement is the term for obsoleting in DICOM - one of the examples we talked through live was 'retiring' the WADO-WS protocol. It's a breaking change because that protocol is no longer defined. I think of the two interchangeably, but perhaps that is a better example.
Gino Canessa (Mar 05 2021 at 22:50):
Lloyd, I meant "safe to use" as shorthand for "you can be confident that this area of the specification is unlikely to have breaking changes, so you can feel safe in the stability of the definition", sorry if that wasn't clear from context. Hopefully any resource in any published version is 'safe' in that it won't cause harm to use it.
If AllergyIntolerance or Encounter are supposed to be in that bucket, it is a problem that they are still low FMM (e.g., 2/3) and we (as a community) should focus on advancing them.
In part, I think the long release cycles are contributing to this. I can't speak to those two resources in particular, but I can speak somewhat authoritatively on the recent history of Subscription. The bulk of the work for the redesign was done in 2019, with many refinements in 2020 (particularly early in the year). For the past... 9-ish months, most of the changes have been related to either documentation (add more) or channels which had not been exercised in the previous years (specifically websockets).
As far as I know R5 is still at least a year out, so optimistically, we're looking at 2022 for publication. We cannot advance the FMM level on anything before then, since there will not be production implementations of resources that haven't been published. By the time those production implementations are out for feedback (2023-2024?), I don't know who is going to be invested enough to push on getting the FMM increased. For reference, we have already had a lot of core participants move on to other projects during the past couple of years.
I also don't expect to see much in the way of changes to the resources in the meantime, because we need more real-world experience to go further and we can't get that without a release.
Lloyd McKenzie (Mar 05 2021 at 23:23):
Continuing the discussion here: https://chat.fhir.org/#narrow/stream/250700-R4A.2FB.2FR5-Discussion/topic/Managing.20change
Grahame Grieve (Mar 09 2021 at 19:06):
the way that the version numbering works at the moment is that we have, instead of major.minor.path, publication.major.minor.
4.x.x means R4, and anything derived from R4 until we publish R5.
4.0.0 and 4.0.1 means that there were minor changes but nothing that changed systems that implement the specification (though systems that use metadata from the spec were all broken)
4.0.0 and 4.1.x means that there are breaking changes, but still in the R4 space.
Grahame Grieve (Mar 09 2021 at 19:07):
the format looks like semver, but isn't. I don't think we can get closer, and I would strongly oppose separating the stated version and the technical version. R4 should be 4.x.x - that makes life simple for many implementers.
Grahame Grieve (Mar 09 2021 at 19:09):
I don't think that the system works well once we start balloting the next major version - it's no longer meaningfully R4. So that's the change I think we should consider, but I don't think I can pre-adopt for a balloted version right now. I've mulled over this for 48 hours while distracted by technical issues in the content to be balloted, and now I have to make the change
Grahame Grieve (Mar 09 2021 at 19:09):
so the ballot will be 4.1.0
Grahame Grieve (Mar 09 2021 at 19:12):
that leaves hanging the question of what the final version of R4B will be :-( but we have time to consider that
Lloyd McKenzie (Mar 09 2021 at 19:57):
Are we constrained to the space of real numbers? :)
David Pyke (Mar 09 2021 at 19:59):
4.1-1i does have a certain ring to it
Michael Lawley (Mar 09 2021 at 20:20):
4.1.0,-1i
Grahame Grieve (Mar 09 2021 at 20:25):
http://sentimentalversioning.org/
Gino Canessa (Mar 09 2021 at 20:25):
Actually, a lot of information can be conveyed even restricting ourselves to reals if we allow expressions for each term. 4.2^2.3^7. =)
Grahame Grieve (Mar 09 2021 at 20:48):
I hope to be retired before we have that many versions
Alexander Henket (Mar 10 2021 at 19:06):
Following 5.0.0-preview1 logic (which is what I always thought it would be and caught off guard with when it wasn't), I'd expect 4.1.0-ballot1 with intent to publish as 4.1.0. Since this version adds functionality in semver terms it makes sense to go with a higher minor version.
I've come to hate and love semver for its labeling rigidity around backward incompatible changes as a major. All vendors I know though are diehard fans of semver (maybe except when they produce versions themselves :-)
Alexander Henket (Mar 10 2021 at 23:05):
As a more #social note: @Niek van Galen took it upon himself to translate semver.org rules to Dutch and with review of myself and some others it actually came to be: https://semver.org/lang/nl/
Josh Mandel (Jun 14 2021 at 15:36):
that leaves hanging the question of what the final version of R4B will be :-( but we have time to consider that
Is there current thinking about what r4b will be (and where/how we'd support version numbering for such a thing as r4c, if we didn't intend to rule that out, at the level of our versioning conventions)?
(TSC is taking up related discussion, and ok hoping to tie this back to our plans in FHIR.)
Grahame Grieve (Jun 14 2021 at 16:52):
discussion on FMG this week, I hope
Last updated: Apr 12 2022 at 19:14 UTC
