Hi Diego,
"... we have to agree to a valid list of words we support for versions, and
this kind of decisions are not easily taken (take for example the possible
lifecycle status of an archetype)."
I agree that we should at least agree a limited list of reserved words
which we are suggesting as -unstable (or -alpha) and -rc, which have very
specific meanings in terms of the adherence of the archetype to the
numbering rules. This 'flag' is purely the minimum required to indicate
how/if the archetype adheres to the formal rules.
Authoring lifecycle states (pre-draft, draft, team review etc) are handled
separately and although it would be better if these were harmonised, they
may differ across different RMs, modelling communities.
I agree that we should avoid breaking the lexical order and re-think
-unstable.
-dev , -alpha, any other suggestions?
Ian
BTW we got rather more deeply into the rest of the renaming proposals
discussions than we had intended! Our immediate priority is to resolve the
V0 question, so that Sebastian get get the next CKM upgrade out of the door.
Ian
On 1 October 2014 14:53, Diego Bosc? <yampeku at gmail.com> wrote:
>
> El 01/10/2014 14:49, "Sebastian Garde" <
> sebastian.garde at oceaninformatics.com> escribi?:
> >
> > Hi Diego,
> >
> > On 01.10.2014 12:54, Diego Bosc? wrote:
> >>
> >> I tested v0 with LinkEHR editor and works just fine.
> >
> > That's great, although in this case I think you are actually being too
> lenient if you strickly stick to the current spec which defines a
> V_IDENTIFIER as
> >
> [a-zA-Z][a-zA-Z0-9_]+(-[a-zA-Z][a-zA-Z0-9_]+){2}\.[a-zA-Z][a-zA-Z0-9_]+(-[a-
> > zA-Z][a-zA-Z0-9_]+)*\.v[1-9][0-9]*
> >
>
> We changed this 6 or 7 years ago when we removed the "v1draft" kind of
> identifiers that were a thing back then. We also allow the definition of
> single letter entities, that this regex does not allow but specifications
> did allow at least back then (not sure if still do). As somebody said "Be
> conservative in what *you* do, be liberal in what *you accept* from
> others" ;)
>
>
> >
> >>
> >> v0 is also fully compliant with SemVer, which means that in theory
> >> archetype identifiers won't need to be changed when we move to ADL1.5
> >> (going with v1-unestable will need another change in the future)
> >
> > v1.0.0-unstable is also fully compliant with SemVer - I don't understand
> why this would require more changes in the future that v0 doesn't need?
> > Sebastian
> >
>
> I said that because we have to agree to a valid list of words we support
> for versions, and this kind of decisions are not easily taken (take for
> example the possible lifecycle status of an archetype).
>
> If we also override the lexic order then we must change it to fully agree
> with semver
>
>
> >>
> >>
> >>
> >> 2014-10-01 12:23 GMT+02:00 Ian McNicoll <ian at mcmi.co.uk>:
> >>>
> >>> Hi all,
> >>>
> >>> Apologies for cross-posting in both clinical and technical but this
> does
> >>> neatly cross that divide.
> >>>
> >>> We are getting close in CKM to implementing the ADL1.5 archetype naming
> >>> /versioning rules proposed at
> >>>
> >>>
> http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification
> >>>
> >>> mostly by adding the metadata to the ADL other_details section, which
> means
> >>> we can carry the information in ADL 1.4 archetypes without disturbing
> >>> current systems.
> >>>
> >>> These latest proposals are now very much in line with the de-facto
> standard
> >>> SemVer 2.0 see http://semver.org which allows
> >>>
> >>> major revision
> >>> minor revision
> >>> patch
> >>> build
> >>>
> >>> but one of the questions which remains controversial is whether to
> support a
> >>> major revision of V0 (as allowed in SemVer).
> >>>
> >>> In Semver, V0 is allowed for very immature ?first draft? semantic
> >>> artefacts/APIs prior to initial release but SemVer allows for any
> revision
> >>> to appended with a pre-release modifier
> >>>
> >>> e.g. v2.0.0-alpha or v1.0.0-unstable
> >>>
> >>> This is recognised as meaning that the artefact is unstable and the
> version
> >>> numbering cannot be relied on e.g to assert backward compatibility.
> >>>
> >>> 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.
> >>>
> >>> So the question for us in the openEHR world is whether tooling should
> >>> support v0.0.0, or simply use v1.0.0-unstable
> >>>
> >>> V0 Advantages
> >>>
> >>> 1. The archetype is clearly marked as immature
> >>> 2. Full compliance with SemVer
> >>> 3. Supported in current test build of CKM
> >>>
> >>> V0 Disadvantages
> >>>
> >>> 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change
> to
> >>> support V0
> >>> 2. Add another layer of complexity to the archetype naming/versioning
> rules
> >>> 3. Question arises of whether / if to convert current draft V1 CKM
> >>> archetypes to V0 with overhead of explanation to current users.
> >>> 4. Adds complexity where V0 archetypes are being used within
> templates, when
> >>> the archetype is published and needs to be updated to V1 within these
> >>> templates.
> >>>
> >>>
> >>> V1- Advantages
> >>>
> >>> 1. Compliant with SemVer
> >>> 2. Does not need any changes to Archetype Editor.
> >>> 3. Easier transition between draft and publication states when used
> within
> >>> templates i.e does not need V0->v1 change
> >>>
> >>>
> >>> V1- Disadvantages
> >>> 1. Does not so clearly differentiate ?first draft? archetype from
> others
> >>>
> >>>
> >>> Before a final decision is made, we are interested in feedback from the
> >>> community on whether V0 should be implemented in CKM and other openEHR
> >>> tools, although in practice V1- will do an identical job in terms of
> version
> >>> number governance.
> >>>
> >>> Regards,
> >>>
> >>> Ian McNicoll
> >>> Heather Leslie
> >>> Sebastian Garde
> >>> Thomas Beale
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> openEHR-clinical mailing list
> >>> openEHR-clinical at lists.openehr.org
> >>>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
> >>
> >> _______________________________________________
> >> openEHR-technical mailing list
> >> openEHR-technical at lists.openehr.org
> >>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> >
> >
> > --
> >
> > Dr. Sebastian Garde
> > Dr. sc. hum., Dipl.-Inform. Med, FACHI
> > Ocean Informatics
> >
> > Skype: gardeseb
> >
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical at lists.openehr.org
> >
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
--
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian at freshehr.com
Clinical modelling consultant freshEHR
Director openEHR Foundation
Honorary Senior Research Associate, CHIME, UCL
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/3ec26155/attachment.html>
