Hi Ian, I would prefer https://github.com/flazz/semver/ , but not explain :) CKM shows archetype revision history tree, but the version is not changed. For example, openEHR-EHR-OBSERVATION.blood_pressure version has been kept 1 in these years, but it has 26 revision up. I think it is non-sense to change version by each revision commit, but meaningful change should be reflected to the version number, such as adding item, fixed typo, translation to other language completed.
Shinji 2014-10-01 23:05 GMT+09:00 Ian McNicoll <ian at mcmi.co.uk>: > Hi Shinji, > > Github is your friend - see https://github.com/npm/node-semver > > but I agree, it is tricky. > > However it is simply not possible to manage the transition between stable > and published archetypes safely by just using numbering alone. We need to > very explicitly flag that unstable state so that it can be parsed safely - > this is what the '-' gives us. We did look at all sort of numbering schemes > and alternatives to Semver but eventually came back to the view that this is > pretty well how it has to work. One big advantage of sticking with Semver is > that we can take advantage of work like the NPM parser, apart from the > > The 'exclusive revision history' (if I understand you correctly) comes from > the Build identifier, identified by a '+' > > So an unstable archetype may be > > v1.0.1-unstable+145567345 > > and after some internal authoring or reviewing goes to > > v1.0.1-unstable+35634512 > > The build identifier is not guaranteed to be sequential and there may well > be breaking changes between the first and second iteration. > > From the developer perspective I can know exactly which build of the > archetype I am using in my system, and that it is unstable. I would be very > unwise to use this in any production system but may of course need it in a > testing phase, or need to support its use within tooling. > > I am not wedded to -unstable , but I think you will find that if you try to > work with some other number=based system, you always hit a problem ,and that > some kind of pre-release signifier is required. > > If we agreed that openEHR would only officially support -unstable (or > -alpha) and -rc, that would greatly simplify the parsing. > > Ian > > > Ian > > > Implementers do not have to parse what comes next > > On 1 October 2014 14:34, Shinji KOBAYASHI <skoba at moss.gr.jp> wrote: >> >> 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 >> >> _______________________________________________ >> 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
