On 01.10.2014 14:55, Ian McNicoll wrote: > Thanks Sebastian, > > You are correct, of course, there is a rule about this, but is just > about lexical matching e.g. -a is allowable and -a < -alpha. The > labels themselves have no meaning. > Yes, not really that nice, is it - it just works coincidentally. That's one reason I said I wouldn't want to use more than one.
> On that basis, perhaps -unstable should be renamed to something > earlier in the alphabet to fit with the matching rule i.e so that it > comes before -rc? Good point. > On the other hand we do have a very specific meaning for rc, which is > that although this is still an archetype in development, it will obey > the versioning rules if it has to change. > Still if we use -unstable and -rc, we cannot claim to fully embrace the SemVer rules for precendence. Sebastian > Ian > > > > On 1 October 2014 13:40, Sebastian Garde > <sebastian.garde at oceaninformatics.com > <mailto:sebastian.garde at oceaninformatics.com>> wrote: > > > 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> <mailto: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 seehttp://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 <mailto: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 <mailto: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-clinical mailing list > openEHR-clinical at lists.openehr.org > <mailto:openEHR-clinical at lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_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 <mailto:ian at freshehr.com> > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org <http://www.phcsg.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/85a8ed93/attachment.html>
