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