I know that a draft is supposed to change, even big breaking changes. what I don't like is the idea of not being able to describe what I am using in my system or even describe it and everyone thinking is another completely different thing
I think the main problem here is that we are using a single axis identifier (v1...) to describe a process that is two axis or more (v1 draft, v2 published) 2011/4/28 Heather Leslie <heather.leslie at oceaninformatics.com>: > Hi everyone, > > I think you are missing some of the further complexity here. There is a > definite need for differentiation between draft and published archetypes for > which a version number alone is not enough. > Currently we are talking only about v1 archetypes and how to manage them, > and to a degree it makes sense. We certainly considered using v0.x for > drafts but it doesn't solve the downstream problems - once a v1 archetype is > published, the non-breaking revisions will become v1.1, 1.2 etc. No problem > But when we make a breaking change it becomes v2 (or v3 or v4 or 125), but > it needs to be clear that it is v2 *draft* initially and not v2 *published* > until we have completed the neccessary collaborative reviews. > > When creating release sets it needs to be clear which are draft and which > are published/stable plus which version, and this is being catered for in > the CKM development. > > As far as the suggestion to create warnings that draft archetypes are 'use > at your own risk'... they can certainly be used at any point eg as the basis > for further work or in a pilot project... whatever. But to be perfectly > frank, I think it is extremely problematic if anyone considers basing any > development or implementation on any artefact or specification labelled > 'draft' and not expect there to be potentially breaking changes arising. > Personally, it seems redundant to add warnings when the status of each > artefact is available - I'd prefer to ensure that the status is perhaps more > prominently visible throughout the CKM and it's processes than add popups > and warnings all over CKM. It is not only per archetype, but per template > where there may be a mix of statuses of archetypes, embedded templates and > subsets etc - the problem becomes incredibly convoluted very quickly as we > are not always talking about single pre-published artefacts. > > Regards > > Heather > > On 28/04/2011 9:49 AM, Diego Bosc? wrote: > > 2011/4/28 Thomas Beale <thomas.beale at oceaninformatics.com>: > > On 27/04/2011 10:44, Diego Bosc? wrote: > > 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? > > it should make no difference, although since the major version number in > openEHR is reserved for breaking changes, one would hope that v27 archetypes > would never occur. However, v2.0.154 or v3.18.26 could be realistic. > > We should have no problem with v0.1 or v0.2.1 then... > If we have two different systems that communicate and they are > referring to different archetypes with the same name then we are > throwing away all the supposed semantic interoperability (Not much > better than using HL7 v2 messages that use different Z segments). > If we want to openEHR to get broader use we can't just tell the people > that have been already using archetypes that the archetypes on their > projects were "not intended to be used" or "you used them at your own > risk". If we want to go that way then we should put at least a warning > on the download page of those archetypes. > > > - t > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > > -- > > Dr Heather Leslie > MBBS FRACGP FACHI > Director of Clinical Modelling > Ocean Informatics > Phone (Aust) +61 (0)418 966 670 > Skype - heatherleslie > Twitter - @omowizard >
