Hi Ian, The idea of v0 was to indicate to people using them that they are unpublished and substantial structural changes are quite likely whilst allowing us to use v1 for the first published version. If anyone used v0 then they do so at their own risk. This is not much different to the current state of play but is more obvious.
Regards Heath Heath Frankel Product Development Manager Ocean Informatics From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Ian McNicoll Sent: Wednesday, 27 April 2011 7:03 PM To: For openEHR technical discussions Cc: For openEHR clinical discussions Subject: Re: Archetype versioning on CKM Hi David, Thanks for this, though I think these are still draft specifications. I had some input into that document but with experience I am not sure the revision rules really work for .v0 archetypes though the .v0 idea itself is useful. The problem is that any structural version changes would force us to move from v0->v1, which is what I think we need to avoid for these first draft archetypes. Once an archetype is published, the rules suggested (mostly) work just fine Ian Dr Ian McNicoll office +44 (0)1536 414 994 +44 (0)2032 392 970 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 27 April 2011 10:15, David Moner <damoca at gmail.com> wrote: 2011/4/27 Ian McNicoll <Ian.McNicoll at oceaninformatics.com> Would calling first draft archetypes .v0 help to highlight their fragility? In fact, that is what the specifications say. Our archetype editors should use 0 when creating a new archetype. (Knowledge Artefact Identification specifications) .v0 rule: all archetypes have this version on initial creation, before being accepted by the collaborative authoring environment; revision id rule: revision number starts at 0 and is incremented whenever a backwards compatible change is made that affects the structure ? by widening constraints and/or adding new nodes; commit id rule: commit number starts at 0 and increments for any change at all to an archetype, including changes to meta-data, addition of translations and so on. An archetype will start its life as a ?v0? artefact, and with no namespace. In this form, it can have any number of revisions and commits. It may be maintained for some time outside a Publishing Organisation, or it may be offered to a PO, where it will initially become part of an ?alpha? development area. where it will remain until its identifier and location in the package and Library structure is stablised. Once stable, an alpha archetype will migrate to the main ?dev? area, where it will be given a namespace prefix and have its version incremented to ?v1?. At this point it could be published into the ?release? area, or alternatively, further development may occur before publishing. Whenever the revision is changed, due to a backwards-compatible structural change, the archetype should be re-published, enabling the community to have access to the latest form of the archetype. During development, each change will increment the commit number. Whenever an archetype is published, the commit number is reset to 0. -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110427/b483524e/attachment.html>
