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 >
