Well I was writing a response to Sebastian, but meantime Ian mail arrived, so I'll answer both summarizing a little.
As I said: changing minimally a DRAFT archetype without increasing version number--> OK changing completely the structure of a DRAFT without increasing version number and erasing the first one (as if it never existed) --> Not OK In the case I was telling, 4 archetypes were completely changed and refactored, changing their complete structure and relationships (even the identifier was different). The refactored archetypes were just deleted from CKM, which is not cool We have more publication status between draft and published. What happens if an archetype is in 'team review' status and then we need a new version (again, breaking changes)? we just delete it? about versioning: I like SemVer a lot. Using that it won't be v56 but v1.2.3 (or v0.1.4). One last thing: In my opinion, openEHR revision policy doesn't have to be CKM specific (and so including CKM specific metadata on the archetype may not be the best idea) 2011/9/9 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>: > Thanks Sebastian, > > That saved me replying to Diego on the first question! > > I agree that we need to make a very clear distinction between the > official 'external' ?openEHR version/revision number arrangement and > any internal design-space ?scheme, used to identify numerous > design-time revisions, which as you say may not ever appear in the > outside world, and may be quite specific to the internal operations of > the repository tool in question. I agree that it would be helpful to > carry this internal design-space numbering information in the > metadata, so that developers who did want to make use of a DRAFT > archetype could know the exact revision if necessary. > > e.g. > > Version = 1 > Revision = 2 > DesignRevision = 134567::345678 > > Ian > > Dr Ian McNicoll > office +44 (0)1536 414 994 > 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 9 September 2011 10:26, Sebastian Garde > <sebastian.garde at oceaninformatics.com> wrote: >> 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 >> >> >> >> _______________________________________________ >> 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 >
