Hi Diego, Ian answered the second, I'll have a go at your first question.
I for one believe it is ok for a DRAFT archetype to be changed in any way without increasing the version number. I don't think that we should start clocking up versions if a DRAFT archetype needs to change in an incompatible way or you are ending up publishing say v27, v35, and then v56 instead of v1, v2, and v3. Technically this may be possible, but I would not see this as desirable. However, what we have to do is to clearly differentiate between revisions and versions of an archetype. Any change to an archetype will clock up the /revision /of the archetype - and will be retrievable e.g. via the CKM Revision History for each archetype. On the other hand, the /version /number should be increased only occur if the following conditions are met: 1. The publication status of the archetype has been published 2. The archetype has changed in a backwardly incompatible way. In this case at /some /stage before republishing the archetype, its version number has to be increased. Note that IMO the version number doesn't have to be increased /immediately/ when the breaking change is taking place. This is because you potentially would want to revert this change later (e.g. after a review round) and go for a less radical, non-breaking change. So - if the currently published revision of the archetype and the new revision to be published are not compatible, then and only then should we need to increase the version number. Imagine for example you are making a breaking change which you need to revert at a later stage. This is not an uncommon situation. Say we start with v1 and due to this change we go to v2 in a draft archetype. Then you make another breaking change (v3) and now during the comprehensive review of the archetype you realise that actually none of this was required and instead a compatible change from v1 (or no change at all) was all that was needed. Now - potentially - you have to go to v4...whereas in reality you are at v1. In this example, v2 and v3 were never intended for anybody's use, they are just intermediate. Of course, all revisions are always available for these archetype - a little less visible, but always accessible via the Revision History of the archetype. This internal revision number (or some corresponding external one) could be part of an extended id of the archetype, or part of its meta data. But it has to be clear that many of these revisions are just intermediate steps and should not be upvalued more than necessary by assigning them a version number on their own. As Ian said in a previous post, the real problem is that we have so many DRAFT archetypes and so few published ones on CKM. In my opinion being able to appropriately resource the editing/publishing process of 'official' openEHR archetypes, should be made one of the top priorities of the transitional board Cheers Sebastian Am 08.09.2011 11:14, schrieb Diego Bosc?: > As I said before, I am perfectly fine with archetypes being volatile, > unstable, and whatever you want. What I don't like is archetypes > disappearing into the 'limbo'. Ignoring the versioning may be OK when > you are just completing the archetype (missing terms, etc.), but > surely is not OK for archetypes with big structural changes (even if > they are draft). > I'm not telling you to show it in the same way that current 'up to > date' archetypes. Hide it to most users, mark it obsolete, deprecated, > put a red flag... there are a lot of alternatives. Having the obsolete > archetypes available also helps you to understand why the new version > was needed on the first place. > > I don't really see the point of leaving the drafts out of the > versioning process (why don't they have any 'official' status in the > first place? incomplete concepts are still concepts). Archetype status > (drafts, published, team review, etc.) and versioning (SemVer?) should > be two completely separated things > > There is another thing I think I haven't quite understand from your > post. Is 'editing' process made by reviewers or is an additional > process to the 'review' process made by a team of editors? If the > editors are all the reviewers (currently more than 200 regarding CKM > statistics) then the real challenge is to involve them (as seems like > most of them are inactive users) > > Diego > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110909/ea47024a/attachment.html>
