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
o 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
o 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.
o 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.
o 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/cf9b9cc0/attachment.html>
