Hi Thomas and all, On 01.10.2014 14:07, Thomas Beale wrote: > On 01/10/2014 11:23, Ian McNicoll wrote: >> In that sense v0.0.0 and v1.0.0-unstable are identical in terms of >> their ?stability? and lack of commitment to the versioning rules. > > > I don't think this is true. Firstly, the standard first possible > version is v0.0.1 in any versioning environment I know of; secondly, > the rules that I thought we were adopting have the following implications: > > * an uncontrolled archetype is uploaded for the first time, with > version v0.N.P > * at some point in the CKM environment is becomes v1.0.0, which is > the first possible version at which it could be published > o let's just say for argument's sake, it is first published at > v1.2.0 > The point when it becomes v1.0.0 is when the archetype is first published - i.e. the first published version will always be 1.0.0 and not v1.2.0 If the transition to v1.0.0 comes from v0.0.1[-unstable] or v1.0.0-unstable doesn't really matter - purely technically speaking the terms of stability and lack of commitment are the same for both 0.0.1[-unstable] and v1.0.0-unstable > > It seems to me a no-brainer that we should support v0, because it's > the clearest possible sign I can think of, that everyone already > recognises, that indicates an artefact to be in early > chaotic/uncontrolled development. So v0 should be the start version > for any archetypes created new on someone's own machine, or any > similar location. > Supporting it as part of the specs for uncontrolled/chaotic development is one thing and I agree. But what we are looking at here is that all CKM archetypes would have a v0 extension until they are first published (as v.1.0.0). Existing pre-publication CKM archetypes would be converted to have a v0 extension (either as a batch or one-by-one when each one is updated the next time)
> * I think that the openEHR.org CKM archetypes identified for the > industry sprint should stay at v1.x, and others that are of > unknown quality should go to v0, which finally establishes what is > clinically trustworthy and what is not. > That's not really an option unless you want to make this migration even more difficult. What you are suggesting requires two different sets of rules and someone needing to deciding which stays at v1 and which is converted to v0. I don't think it makes sense - either we use v0 to indicate pre-publication archetypes or we don't. > > * I don't see the problem with v0 references in templates, since > it's the same problem between any major version. An archetype > xxxx.v0.x can't be assumed to be compatible with xxxx.v1.y - as > for other major versions, we treat them technically as different > archetypes. So either the template reference is v* (any major > version you like) or it isn't, in which case it points to a known > major version - v0, v1, v2 or other. > o we should assume that future tools will make it easy to change > these template references - it won't be difficult to do. > Sure, looking forward to tooling support on it, but realistically at the moment it is a pain that is not needed for the first publication if you go with v1 as a the initial major version. Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/dd4685b1/attachment-0001.html>
