On 01.10.2014 14:57, Thomas Beale wrote: > On 01/10/2014 13:31, Sebastian Garde wrote: >>> >>> It seems to me a no-brainer that we should support v0, because it's >>> the clearest possible sign I can think of, that everyone already >>> recognises, that indicates an artefact to be in early >>> chaotic/uncontrolled development. So v0 should be the start version >>> for any archetypes created new on someone's own machine, or any >>> similar location. >>> >> Supporting it as part of the specs for uncontrolled/chaotic >> development is one thing and I agree. >> But what we are looking at here is that all CKM archetypes would have >> a v0 extension until they are first published (as v.1.0.0). >> Existing pre-publication CKM archetypes would be converted to have a >> v0 extension (either as a batch or one-by-one when each one is >> updated the next time) > > that sounds right to me - is it a problem? > This is what works in a CKM test version, so no it is no problem (but is certainly more complex than it may sound) >>> >>> * I think that the openEHR.org CKM archetypes identified for the >>> industry sprint should stay at v1.x, and others that are of >>> unknown quality should go to v0, which finally establishes what >>> is clinically trustworthy and what is not. >>> >> That's not really an option unless you want to make this migration >> even more difficult. >> What you are suggesting requires two different sets of rules and >> someone needing to deciding which stays at v1 and which is converted >> to v0. >> I don't think it makes sense - either we use v0 to indicate >> pre-publication archetypes or we don't. > > I would have thought that individual archetypes can have their version > modified? I don't think the world minds if there is a period of a few > months during the industry sprint when the rules are technical being > broken. Once it's done, there will be 70+ archetypes with v1.x, and > the rest with v0.x, and that will correctly represent the situation of > the archetypes in CKM. > You are trying to eat your cake and have it. For semantic versioning to be implemented in CKM, the version numbers need to be under CKM control. And then for your revisioning to work, CKM needs to know which archetypes should be converted and which ones shouldn't and then apply different versioning rules to them. I see no reason to add to the complexity like this.
> Then for every mirroring, copy, and reuse of what's in openEHR.org > CKM, there is no need to educate anyone on anything - it's obvious > what the situation is. So we are only talking about a limited period > of time where the rules are being broken (as they are right now in > fact ;-) >>> >>> * I don't see the problem with v0 references in templates, since >>> it's the same problem between any major version. An archetype >>> xxxx.v0.x can't be assumed to be compatible with xxxx.v1.y - as >>> for other major versions, we treat them technically as different >>> archetypes. So either the template reference is v* (any major >>> version you like) or it isn't, in which case it points to a >>> known major version - v0, v1, v2 or other. >>> o we should assume that future tools will make it easy to >>> change these template references - it won't be difficult to do. >>> >> Sure, looking forward to tooling support on it, but realistically at >> the moment it is a pain that is not needed for the first publication >> if you go with v1 as a the initial major version. > > well I think its a bigger danger, given the level of reuse of CKM > archetypes, that the version ids wouldn't correct reflect the state of > the archetypes. We could in theory revert everything that is not > published to v0 right now, and i guess that is breaking the rules for > less time. I don't care when it is done. It can either be as a batch or each time you change an archetype next. But when you change it next, CKM then needs to apply the correct revisioning rules to it or it will just be an endless migration mess. > But there are still some dozens of fully reviewed and published > archetypes that have to retain their v1.x version anyway. I don't see your problem. Naturally, published archetypes would not change their .v1 version to .v0. > So I think the only question is to do with the industry sprint > archetypes. How about doing this: > > * mark archetypes that have never been 'published' and are not in > the industry sprint as v0.5.0 > * mark the industry sprint archetypes as v1.0.0-unstable > * leave currently published archetypes on v1.x, i.e. where they are > today. > As above, then you are applying two different set of rules for migration, depending on whether the archetype is in the industry sprint or not. Apart from the additional complexity I tried to explain, what is the point? The only point I can see is that you want to identify industry sprint archetypes: I think they are all part of one project now and you can easily get them from there. > If I receive a copy of archetypes marked like that in say the GitHub > mirror, or through a different CKM, I don't need any further > education, it's obvious what's going on. Well, I for one, would not understand without your explanation that the difference between 0.5.0 and 1.0.0-unstable is that the one is in industry sprint and the other isn't. There are more logical ways to me to find this out (just look at the CKM project). Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/fa01a433/attachment-0001.html>
