Erik, thanks for the pointer. I like this set of rules. It is not too different from the current draft identification spec <http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf>, and it would be easy to upgrade it to reflect the SemVer rules more faithfully. In the openEHR spec, major.minor.patch is referred to as version.revision.build. I seem to remember a discussion where we thought about renaming these. Do people think we should just stop mentioning version/revision/build with respect to archetypes? Or is it helpful to think of an openEHR 'revision' as being the same as a 'minor' version (personally I think yes)?
The only thing I don't like that much is going back to putting 'draft' etc on the end of the version string, but I guess it is so common, that we should just go with the flow. If we can get a bit of consensus here, I can update this draft proposal to reflect it pretty quickly. - t On 14/06/2011 09:24, Erik Sundvall wrote: > Hi! > > I came to think of this openEHR versioning discussion thread when I > read about the Semantic Versioning initiative at http://semver.org/ > > I think the reasoning there is very appropriate also for openEHR artifacts. > > The problem for openEHR might be that there are so many seemingly > usable archetypes in the openEHR-hosted CKM that are neither modified > for a long time nor officially tagged as "published". It is > understandable if it's tempting to start using them in real systems > already now. After all the alternative is to reinvent the wheel > locally and is that really better? Perhaps there should be a time > limit on how long artifacts in the CKM can stay at a version below > 1.0.0? > > Perhaps things would become easier if we break the link between an > artifact having "published" status (as in being CRB approved) and the > fact that an artifact has a version over 1.0.0. That way systems can > start using archetypes past 1.0.0 knowing that non-compatible changes > will have new major version numbers (irrespective of if they are > published or not). > > Keeping approval "badges" like "ARB published", "NHS approved" or "WHO > 2011 Certified" separate from technical version numbers might be a > good idea anyway... (Example: the first "ARB published" version of > Archetype X might be 2.4.2 and the next time it's awarded an "ARB > published" badge again might be when the ARB has time to get around to > looking at version 2.8.4 or 7.8.9). Likely, agencies will want to > approve sets of artifacts on a regular basis like tagging a number of > mutually compatible archetypes and templates as "NHS 2012-Q1 > approved". > > The reasoning under #3 at http://semver.org/ (regarding 1.0.0beta1< > 1.0.0beta2< 1.0.0.) might solve the "draft problem" discussed in this > openEHR thread previously. (Provided that beta versions etc. don't get > used/abused in live EHR systems.) > > The Semantic Versioning specification formalism is also machine > processable in a nice way. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > > > > On Thu, Apr 28, 2011 at 13:41, Thomas Beale > <thomas.beale at oceaninformatics.com> wrote: >> On 28/04/2011 02:07, Heather Leslie wrote: >> >> 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. >> >> There are two ways to look at this: >> >> A - 'draft' is only possible at the notional v0 or first version stage; >> after initial publication, it can't be used, since the archetype is now 'in >> the open' >> B - it is possible to go back to 'draft' status when the major version >> number is incremented on the basis that a new major version is a new >> archetype, and authors need to be able to go back into 'initial development' >> mode >> >> I can see arguments for both. What we need to decide on as a community is >> what rule we want here, and to stick to it. If we can decide that, we can >> document it and post it in a new draft of the identification specification. >> >> Diego's problem of knowing what archetype one is actually using is real and >> needs to be solved. CKM does track revision numbers, but they are not part >> of the version id, and you have to go into the revision history view to see >> them. However the above-mentioned identification draft spec indicates a >> system of referencing to do this such that an archetype whose id is >> currently shown as openEHR-EHR-EVALUATION.diagnosis.v1 would be referenced >> from data and / or software (i.e. in any operational context) as >> openEHR-EHR-EVALUATION.diagnosis.v1.29.0, or in the future with a namespace >> as well, i.e. org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29.0 >> >> Note that in this system of identification, if the final part of the >> revision number is a '0', i.e. the '0' above in '1.29.0', it means that the >> archetype is published; if it is anything else it is draft or some other >> pre-release state (this corresponds with view B above). Changes in the >> lifecycle state of the archetype are assumed to always cause an increment in >> final number of the extended version id. >> >> A fuller idea of referencing archetypes from from data is described in this >> spec, exemplified by the following: >> >> se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12, -- some Swedish >> archetype >> org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29, -- its parent, >> the CKM diagnosis archetype >> org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4 -- the ultimate >> parent, the CKM problem archetype >> >> here the whole specialisation lineage has been included. The reason for >> doing this are a) if the archetype lineage information is not shared between >> sender and receiver (maybe the receiver can't see the Swedish CKM) and b) to >> enable the receiver to know what archetypes could be used for querying the >> data, assuming it was not going to use the most specialised one (e.g. the >> data might have been sent from Sweden to Denmark, and the Danish system >> doesn't use the Swedish genetic diagnosis archetype, but does use the other >> two). >> >> Note that the version ids above only have 2 parts, because the final part is >> always '0' for published archetypes (but it could be included for better >> consistency). >> >> Assuming this kind of system was used, then supporting it requires some >> changes in CKM to a) make the full version + revision id visible. >> >> Note that the 'identifiers' above are just strings. Even in a future where >> Oids were used for identifying artefacts, you still need to generate the >> above strings, or the equivalent, from meta-data - essentially as composite >> keys (in the relational sense) so that comparisons can be made between >> artefacts. (Or they might also be obtainable from some Oid-keyed meta-data >> repository). In other words, embedding such strings in data isn't making a >> statement about how archetypes are identified, it is just one useful means >> of referencing archetypes. >> >> Finally, to be sure that the archetype you have in your environment is >> indeed what you think it is, digital signing, or at least hashing, is needed >> such that published archetypes are posted with their signatures alongside >> for verification by accessing systems. MD5-based hashing is already in use >> in some openEHR-based products, but it has not been properly described (an >> initial idea is in section 8 of the identification spec doc). >> >> It seems that there is enough use of archetypes now to finalise many of >> these issues, and describe them in a new issue of the identification >> specification. We then need to work out an implementation plan, mostly to do >> with changes to CKM to support the decisions. >> >> There are two ways to go about this: >> >> interested parties review the identification spec, and provide feedback >> we work out the details on the technical list + wiki via discussion and then >> update the spec. >> >> Key things that need decisions: >> >> do we go with starting at v0 or v1 (I still like v0 because it implies 'you >> will most likely get burnt by using this archetype in a real system, but >> have fun and tell us your experience')? >> can we agree on the archetype life-cycle states and the idea that a change >> in state always causes an increment in minor revision number? >> how should archetypes be referenced from data? >> what system of hashing and signing should be used? >> >> - thomas >> >> >> _______________________________________________ >> 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 > -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110616/85351743/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110616/85351743/attachment.jpg>
