Hi Diego,
On 01.10.2014 12:54, Diego Bosc? wrote:
> I tested v0 with LinkEHR editor and works just fine.
That's great, although in this case I think you are actually being too
lenient if you strickly stick to the current spec which defines a
V_IDENTIFIER as
[a-zA-Z][a-zA-Z0-9_]+(-[a-zA-Z][a-zA-Z0-9_]+){2}\.[a-zA-Z][a-zA-Z0-9_]+(-[a-
zA-Z][a-zA-Z0-9_]+)*\.v*[1-9]*[0-9]*
> v0 is also fully compliant with SemVer, which means that in theory
> archetype identifiers won't need to be changed when we move to ADL1.5
> (going with v1-unestable will need another change in the future)
v1.0.0-unstable is also fully compliant with SemVer - I don't understand
why this would require more changes in the future that v0 doesn't need?
Sebastian
>
>
> 2014-10-01 12:23 GMT+02:00 Ian McNicoll <ian at mcmi.co.uk>:
>> Hi all,
>>
>> Apologies for cross-posting in both clinical and technical but this does
>> neatly cross that divide.
>>
>> We are getting close in CKM to implementing the ADL1.5 archetype naming
>> /versioning rules proposed at
>>
>> http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification
>>
>> mostly by adding the metadata to the ADL other_details section, which means
>> we can carry the information in ADL 1.4 archetypes without disturbing
>> current systems.
>>
>> These latest proposals are now very much in line with the de-facto standard
>> SemVer 2.0 see http://semver.org which allows
>>
>> major revision
>> minor revision
>> patch
>> build
>>
>> but one of the questions which remains controversial is whether to support a
>> major revision of V0 (as allowed in SemVer).
>>
>> In Semver, V0 is allowed for very immature ?first draft? semantic
>> artefacts/APIs prior to initial release but SemVer allows for any revision
>> to appended with a pre-release modifier
>>
>> e.g. v2.0.0-alpha or v1.0.0-unstable
>>
>> This is recognised as meaning that the artefact is unstable and the version
>> numbering cannot be relied on e.g to assert backward compatibility.
>>
>> In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their
>> ?stability? and lack of commitment to the versioning rules.
>>
>> So the question for us in the openEHR world is whether tooling should
>> support v0.0.0, or simply use v1.0.0-unstable
>>
>> V0 Advantages
>>
>> 1. The archetype is clearly marked as immature
>> 2. Full compliance with SemVer
>> 3. Supported in current test build of CKM
>>
>> V0 Disadvantages
>>
>> 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to
>> support V0
>> 2. Add another layer of complexity to the archetype naming/versioning rules
>> 3. Question arises of whether / if to convert current draft V1 CKM
>> archetypes to V0 with overhead of explanation to current users.
>> 4. Adds complexity where V0 archetypes are being used within templates, when
>> the archetype is published and needs to be updated to V1 within these
>> templates.
>>
>>
>> V1- Advantages
>>
>> 1. Compliant with SemVer
>> 2. Does not need any changes to Archetype Editor.
>> 3. Easier transition between draft and publication states when used within
>> templates i.e does not need V0->v1 change
>>
>>
>> V1- Disadvantages
>> 1. Does not so clearly differentiate ?first draft? archetype from others
>>
>>
>> Before a final decision is made, we are interested in feedback from the
>> community on whether V0 should be implemented in CKM and other openEHR
>> tools, although in practice V1- will do an identical job in terms of version
>> number governance.
>>
>> Regards,
>>
>> Ian McNicoll
>> Heather Leslie
>> Sebastian Garde
>> Thomas Beale
>>
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Ocean Informatics
Skype: gardeseb
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/b942d273/attachment.html>
