Hi! On 12/09/2012 17:43, Heath Frankel wrote: > We need a depreciation scheme that allows us to say that something > is no longer recommended for use in a particular release and removed > in a subsequent release. This gives implementations time to migrate to > the new recommendation. It also means we can get some experience > with what the new recommendation is before we remove the deprecated > approach.
Yes, what about using that approach (deprecation scheme etc) for a "stable" or "production grade" series of versions - v 1.0.3, v 1.1 and so on... ...and at the same time start working on an "experimental" 2.x series. This is how it is often done in big open source projects (with a lot bigger user base than openEHR has). Critical systems, in production use, seldom jump over to the new 2.x series while it is young, they wait for it to mature. BUT they have been able to follow and comment on the 2.x development all along the way so that they can be prepared without constraining the options by insisting on full backwards compatibility. The 1.x branch could also slowly make changes to prepare for a simplified future transition to 2.x including adding transformation tools. If we want 13606, CIMI and openEHR modelling to merge somewhere in 2.x, the we can not express too much protectionism from openEHRs side. (I think I have heard people complaining about HL7 protectionism on these lists...) Truly good changes (simplifications, increased archetyping flexibility etc) should not be stopped by protectionism, but of course things should be well tested in implementation before new specifications are finalized. It would be great if e.g most of the future ISO 13606 version could be a true subset of openEHR instead of the current confusing situation. In the openEHR 1.x to 2.x case perhaps we will understand each other better if we discuss concrete examples rather than expressing unspecified fears from both "sides", I'll start one below. Feel free to add other examples (a concrete example of proposed data type changes for example). When you look at http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model, do you then think that the discussed changes at e.g. ENTRY and ITEM_STRUCTURE level will reduce bloat and misunderstandings, at the same time as it increases flexibility and understanding? Would that be truly good for openEHR archetyping and implementation? Ian, an experienced archetype developer, has been asking for this increased flexibility, see: http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=32210974#comment-32210974. (I think Sam also mentioned similar thoughts on the lists earlier.) I had guessed that those proposed changes are big and breaking enough to go for 2.x rather than a "soft deprecation" 1.x series, what is the opinion of those of you that have big systems running? Do they fit in a 1.x series upgrade path? I thought anything that breaks paths would likely be considered a "big" change. (In the example above, the transition path including automated data conversion is pretty clear though.) It is probably better to break these paths in an experimental 2.x series now rather than waiting five+ years and try to squeeze it in to 1.8 or something. :-) > HL7 [...] look what happened when they offered a major upgrade. [...] > The big issue was the effort for vendors to transition existing systems I think that might be a somewhat unfair comparison: 1. The proposed openEHR 2.0 changes I have seen so far are not deviating from the basic design principles and design patterns in openEHR. The basic approach does _NOT_ change the same way as HL7 did between v2 and v3. 2. The number of vendors using openEHR now is _a lot_ smaller than the ones that used HL7 v2 3. The number of vendors we want to join the openEHR approach in the future is _a lot bigger_ than the ones that have existing openEHR-based production systems. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120913/1a6a3d54/attachment.html>
