On 01.10.2014 14:04, Shinji KOBAYASHI wrote: > Hi Ian, > > I prefer V0, because it would be easier to adopt for other developers > who do not know openEHR well. > For parser implementation, 1.0.0-unstable is not a good design, > because it is not clear that which is the later release amongs, > unstable, testing, pre-release, release-candidate, draft, etc... Actually, this is clearly defined by SemVer, see rule 11: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. But I don't think we would usually want to do this at all for unstable archetypes. They are just unstable, no guarantee whatsoever. If you want to have a specific one, you can always use the unique build id for that. Sebastian > I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the > revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99. > > Shinji > > 2014-10-01 19:23 GMT+09: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-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. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/cf40ece8/attachment-0001.html>
