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.
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? 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. Ian On 1 October 2014 13:40, Sebastian Garde < 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> <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 listopenEHR-technical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://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 > > 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 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/a7077055/attachment.html>
