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. > Please be careful about backward compatibility of our RM, its core to > our foundation. > Heath > > * > *
One key approach that we can use for adding breaking fixes to classes is to actually add a new class. For example, a new version of ARCHETYPE_SLOT is needed in the AOM. The way I would propose to do this is not to 'fix' the existing ARCHETYPE_SLOT, but to add a new class ARCHETYPE_SLOT2 or SEMANTIC_SLOT or whatever, and enhance existing compilers to handle the new one, and to know how convert between both. This is just an example - there are probably similar instances of breaking changes in the RM. Many change requests I am aware of would not break existing data. The main ones we need to be careful with are structural changes to Entry classes and to the Participations model. We need of course to analyse all the proposed changes carefully, but by now we have a reasonable number of implementers, and they will need to be present on the new specifications editorial committee to help assess impact of any given change. So... we just need to do good engineering thinking on this. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120912/6dac50e5/attachment.html>
