Hi Ian. I have read once SemVer, but it is still confusing about suffix. especially "alpha.11 > alpha.beta > beta.1" sequence. This needs tricky grammar rule to parse.
Hi Sebastian, I think revision history should be exclusive, even it is unstable version. Regards, Shinji 2014-10-01 21:26 GMT+09:00 Ian McNicoll <ian at mcmi.co.uk>: > 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 > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
