I still don't see the problem If we wait until an archetype is published to care about versions then you will have v2 or v3 archetypes as much, which in my opinion breaks completely versioning purpose. What is the problem with having a v27 archetype? Is it less pretty?
2011/4/27 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>: > 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 >> > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >
