Hi Diego, Just to be clear, under ADL1.4 the -unstable suffix (and other naming metadata) will not be added to the archetypeID but will be carried in the other_details metadata, so it does not disrupt current tooling. It is up to developers to decide how much of that metadata to make use of for now. When we move to ADL1.5 these new 'other_details' metadata items will become formal AOM and RM attributes but I think Thomas plans to keep the core archetype_id identical, again to minimise disruption.
The only exception in ADL 1.4 is that V0 (if adopted) will potentially break some tooling or back-end systems. None of the other changes should cause things to break as long as other_details is supported correctly. Glad to hear LinkEhr is behaving correctly. We have made some changes to Archetype Editor, which will be released shortly, to ensure that other_details behaves equally well!! So until ADL1.5 comes along -unstable will not break anything. Semver does not actually specify which 'pre-release' labels are allowable. After a lot of discussion we decided that there were really only 2 pre-release states that have semantic significance in openEHR (and probably other archetypes) unstable => This archetype is in development or re-development and the formal Major/Minor/Patch identifiers cannot be relied upon as an indicator of whether the archetype is backwardly compatible i.e once the archetype enters an unstable state, the formal version numbering will remain unchanged, even though the archetype itself is not backwardly compatible. The major/minor/patch numbers will only be adjusted at time of publication or re-publication or when it goes into pre-release state - se next pre-release=> This archetype is still in development but the authors are confident that any future changes that are made will be trivial, and as such are prepared to adhere to the formal version numbering rules, just as if the archetype was fully published. CKM will not allow 'pre-release' to be set (for now). We can discuss allowing alpha, beta etc but really all that developers need to know is that once the -unstable flag is set, they need to be aware that this archetype is really not fit to be used operationally and is 'at your own risk'. The additional Build number identifies the archetype instance very specifically. Ian On 1 October 2014 11:54, Diego Bosc? <yampeku at gmail.com> wrote: > I tested v0 with LinkEHR editor and works just fine. > I think that 'v1.0.0-unstable' has additional problems, such as > deciding which words are allowed (e.g 'unstable', 'firstdraft', > 'alpha', etc.), which means that tools have to be modified anyway. > Arguably, is better to widen a range than to parse specific strings > which end changing in the end. > > Also, adding this breaks all current v1 slots (related to my last > question to the list) > > 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) > > > > 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 Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/7757fd2a/attachment.html>
