Hi Thomas, I agree with all you haver said but would stick to my original assertion that for *practical' and computable purposes, in terms of fitness to be used in an operational system and adherance to the version number rules, v0.0.1 and v1.0.1-unstable are identical.
Both, when published will end up as V1.0.0, both are unstable. I can see the human argument for differentiating a truly feral archetype from one in a controlled repository but am not convinced that this outweighs the hassle of supporting V0 in ADL1.4. When we move to ADL1.5 tooling and downstream systems will need to be changed in any case, so perhaps that is the point to formally introduce V0? Agree with your other points and examples. Ian On 1 October 2014 13:07, Thomas Beale <thomas.beale at oceaninformatics.com> 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. > > > Hi Ian, > > 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 > - let's just say for argument's sake, it is first published at > v1.2.0 > - later, it goes back for revision, which means according to the state > diagram in the latest draft > > <http://www.openehr.org/wiki/download/attachments/5996562/artefact_lifecycle_versioning.png?version=3&modificationDate=1412031989000&api=v2>, > its next version has to be v1.2.1-unstable, i.e. one patch ahead of v1.2.0, > the last published version > - the meaning of this, as I understood it was that this version is > 'at least' one patch level different from the version at the preceding > patch value (v1.2.0), and also unstable, meaning that it might have more > differences than jst that. > - when it is ready for publishing, its version is adjusted, with the > help of a diff tool, to the actual version it is required to be according > to the type of diffs present. E.g. it might have to be v1.3.0. So the new > vresion is either v1.3.0 or v1.3.0-rc.B, if the release candidate path is > being used. > > 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. > > I'm not that worried about 'compliance with SemVer' - it's more that v0 is > universally understood as indicating early chaotic development - it's a > universal 'play with me, but don't trust me' sign. > > By that argument we also know that any version v1 or higher must be from a > controlled governance environment like a CKM or similar. > > In terms of possible concerns listed below: > > - There is no doubt changes are needed to various tooling, but that's > the situation anyway, e.g. to implement namespaces or other changes. > - 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. > - You might possibly petition the clinical list to find out if anyone > has ever used an archetype mooted for v0 renaming, in any production > context. > - 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. > - we should assume that future tools will make it easy to change > these template references - it won't be difficult to do. > > I may still be missing something here, so this analysis is what seems > sensible to me based on what I know today. > > - thomas > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -- 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 Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d1d15b1d/attachment.html>
