Hi Shinji, Can I suggest you read the semver.org specifications? Semver is now used pretty widely in systems and tooling (including the nodeJS Package Manager NPM). We have taken the - suffix directly from those specifications and in other respcts we are now following semver exactly so there should be open source parsers out there that can be used.
Semver exists because we have to treat semantic specifications differently from normal software builds. In normal software alpha, beta, pre-release and indeed the numbering chosen do not need to have any computable significance. Windows 9 is only called Windows 9 for marketing reasons ,not because it represents a breaking change. My recent Yosemite Beta 3-> Beta 4 update may make all sorts of breaking changes but is still a Beta and appears to be only a build different from the Developer Pre-release Yosemite candidate. When we are dealing with Semantic artefacts such as APIs or archetypes, the numbering scheme and suffixes have very specific meanings and rules, to do with backward compatibility. The -suffix is necessary to make it very clear that this is a pre-release artefact and that the normal versioning rules do not apply. What comes after the suffix does not really matter and The prime responsibility we have as archetype authors is to make sure that developers know whether they are working with a stable, published archetype which has followed the versioning rules, or an unstable archetype where those rules are temporarily suspended. It is impossible to do this clearly with a numbering schema alone which is why the - suffix is well-established in SemVer and the tools which use it. In normal circumstances unstable archetypes would never be used in production systems. Ian On 1 October 2014 13:04, Shinji KOBAYASHI <skoba at moss.gr.jp> 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... > 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 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/5e3acadc/attachment.html>
