On 01/10/2014 13:31, Sebastian Garde wrote:
>
>> It seems to me a no-brainer that we should support v0, because it's
>> the clearest possible sign I can think of, that everyone already
>> recognises, that indicates an artefact to be in early
>> chaotic/uncontrolled development. So v0 should be the start version
>> for any archetypes created new on someone's own machine, or any
>> similar location.
>>
> Supporting it as part of the specs for uncontrolled/chaotic
> development is one thing and I agree.
> But what we are looking at here is that all CKM archetypes would have
> a v0 extension until they are first published (as v.1.0.0).
> Existing pre-publication CKM archetypes would be converted to have a
> v0 extension (either as a batch or one-by-one when each one is updated
> the next time)
that sounds right to me - is it a problem?
>
>> * I think that the openEHR.org CKM archetypes identified for the
>> industry sprint should stay at v1.x, and others that are of
>> unknown quality should go to v0, which finally establishes what
>> is clinically trustworthy and what is not.
>>
> That's not really an option unless you want to make this migration
> even more difficult.
> What you are suggesting requires two different sets of rules and
> someone needing to deciding which stays at v1 and which is converted
> to v0.
> I don't think it makes sense - either we use v0 to indicate
> pre-publication archetypes or we don't.
I would have thought that individual archetypes can have their version
modified? I don't think the world minds if there is a period of a few
months during the industry sprint when the rules are technical being
broken. Once it's done, there will be 70+ archetypes with v1.x, and the
rest with v0.x, and that will correctly represent the situation of the
archetypes in CKM.
Then for every mirroring, copy, and reuse of what's in openEHR.org CKM,
there is no need to educate anyone on anything - it's obvious what the
situation is. So we are only talking about a limited period of time
where the rules are being broken (as they are right now in fact ;-)
>>
>> * I don't see the problem with v0 references in templates, since
>> it's the same problem between any major version. An archetype
>> xxxx.v0.x can't be assumed to be compatible with xxxx.v1.y - as
>> for other major versions, we treat them technically as different
>> archetypes. So either the template reference is v* (any major
>> version you like) or it isn't, in which case it points to a known
>> major version - v0, v1, v2 or other.
>> o we should assume that future tools will make it easy to
>> change these template references - it won't be difficult to do.
>>
> Sure, looking forward to tooling support on it, but realistically at
> the moment it is a pain that is not needed for the first publication
> if you go with v1 as a the initial major version.
well I think its a bigger danger, given the level of reuse of CKM
archetypes, that the version ids wouldn't correct reflect the state of
the archetypes. We could in theory revert everything that is not
published to v0 right now, and i guess that is breaking the rules for
less time. But there are still some dozens of fully reviewed and
published archetypes that have to retain their v1.x version anyway. So I
think the only question is to do with the industry sprint archetypes.
How about doing this:
* mark archetypes that have never been 'published' and are not in the
industry sprint as v0.5.0
* mark the industry sprint archetypes as v1.0.0-unstable
* leave currently published archetypes on v1.x, i.e. where they are today.
If I receive a copy of archetypes marked like that in say the GitHub
mirror, or through a different CKM, I don't need any further education,
it's obvious what's going on.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d527e646/attachment-0001.html>
