On 16/06/2011 09:24, Thomas Beale wrote:
>
> Erik,
> thanks for the pointer. I like this set of rules. It is not too
> different from the current draft identification spec
> <http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf>,
>
> and it would be easy to upgrade it to reflect the SemVer rules more
> faithfully. In the openEHR spec, major.minor.patch is referred to as
> version.revision.build. I seem to remember a discussion where we
> thought about renaming these. Do people think we should just stop
> mentioning version/revision/build with respect to archetypes? Or is it
> helpful to think of an openEHR 'revision' as being the same as a
> 'minor' version (personally I think yes)?
>
> The only thing I don't like that much is going back to putting 'draft'
> etc on the end of the version string, but I guess it is so common,
> that we should just go with the flow.
>
> If we can get a bit of consensus here, I can update this draft
> proposal to reflect it pretty quickly.
>
> - t
> *
> *
I meant to add that the SemVer concept of 'public API' for an archetype
will obviously be something a bit different from a standard software
API, i.e. set of class/function definitions. So the 'public API' itself
will be part of what needs to be described. We can potentially interpret
the version rules below for openEHR (for versions above 1.0.0; prior to
that, you do what you want):
7. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards
compatible bug fixes are introduced. A bug fix is defined as an internal
change that fixes incorrect behavior.
openEHR:
* increment patch version ('build') incremented if change limited
errors are corrected so that the original intention is preserved.
Q: how do we document what the 'original intention' was?
8. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MAY be
incremented if substantial new functionality or improvements are
introduced within the private code. It MAY include patch level changes.
openEHR:
* increment minor version (openEHR 'revision') if change limited to
compatible additions; in openEHR-land, the idea is that data of a
previous revision remains conformant to new form of archetype. The
general rule with constraints is that this can be done by:
o widening existing constraints
o adding new constraints not incompatible with existing
constraints, i.e. at a clinical/domain semantic level
9. Major version X (X.y.z | X > 0) MUST be incremented if any backwards
incompatible changes are introduced to the public API. It MAY include
minor and patch level changes.
openEHR:
* increment major version (openEHR 'version') if change causes
archetype to no longer be compatible with existing data. In
openEHR, a new 'version' is a treated like a new archetype, hence
the use of the top-level version number in the semantic identifier.
some more work is obviously needed to get all this where it needs to be,
but I think the SemVer rules look like a good basis to hang openEHR
principles on.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110616/09dfd4ce/attachment.html>
