java - FHIR迁移和向后兼容性

Question

作为系统实现者，当我们从一个版本的FHIR迁移到另一个版本时，我们面临着一个难题。我们从FHIR 0.0.81开始使用，然后在2014年9月10日移至SVN 2833版，以合并错误修复程序。如建议的那样，我们从SVN干线上下载了Java代码，并按照FHIR Build Process page上的指示进行操作。

FHIR 0.0.82不兼容

现在FHIR 0.0.82已可用，我们想升级到发行版本。但是，在下载0.0.82之后，我们注意到主干rev2833中的一些资源(例如，约会)不在0.0.82版本中。这引出了我们的第一个问题:

如果主干不包含预定用于下一个版本的最新代码，则干线包含什么？

应该有人使用行李箱里的东西吗？

是否有从0.0.82创建发行版本的分支？

行李箱不兼容

由于我们的代码依赖于中继上引入的资源，但不包含在0.0.82中，因此我们必须继续直接从SVN检出FHIR。 2014年10月21日，我们下载了SVN版本3218 Java代码。当我们将该代码集成到系统中时，我们发现了许多兼容性问题。这里是其中的一些:

各种Enum值从小写变为大写，包括Patient.AdministrativeGender和HumanName.NameUser。尽管遵循Java命名约定是一个好主意，但是更改基本数据类型会破坏编译。

方法名称已更改，还导致编译错误。我们还发现同时发生了名称更改。例如，在HumanName类中，旧的setTextSimple(String)现在是setText(String)，而旧的setText(StringType)现在是setTextElement(StringType)。 setText()的名称和参数类型均已更改，因此容易发生迁移错误，因为必须在每次使用时决定是否更改方法或其参数。

ResourceReference资源类型已更改其类名。仅在FHIR模型程序包中，就有61个文件中的859个ResourceReference出现。这不包括通过其他FHIR软件包引起的更改，也不会包括通过我们的应用程序代码和数据库架构引起的更改。

我们在rev3218主干代码中注意到了几个新资源，包括NewBundle。以前，我们建议捆绑软件应该是资源，因此很高兴看到这一变化。但是，由于trunk与0.0.8x版本不向后兼容，因此我不确定是否必须同时支持解析和组合JSON和XML捆绑包的旧方法和新方法。

为了更好地说明问题，必须认识到上述某些FHIR更改不仅会影响编译，而且很容易在运行时引入细微的错误。另外，FHIR更改可能需要更改某些应用程序中的数据库架构和数据迁移。例如，我们的应用程序将JSON资源流保存在数据库中。将枚举值从“male”更改为“MALE”之类的简单操作就需要迁移实用程序来更新现有数据库内容。

向前走

我们正在对FHIR进行大量投资；我们希望它能够成功并被广泛采纳为标准。为了做到这一点，需要解决向后兼容性和版本迁移的问题。徒劳的，可以阐明以下问题的一切将使我们共同前进:

0.0.8x代码行的用途是什么？它的目标用户是谁？

干线代码的目的是什么？它的目标用户是谁？

是否会期望0.0.8x的用户迁移到主干代码库？

如果是这样，将使用什么迁移策略来解决代码库之间的许多不兼容性？

每个代码库中的代码弃用策略是什么？

在主干的代码中，从修订到修订，可以期望什么水平的向后兼容性？

是否有FHIR路线图供系统开发人员用来计划自己的开发周期？

谢谢，
富C

Answer 1

我很抱歉没有记录版本控制对Java参考实现的影响。我会的我将假定您熟悉此处的版本控制策略:http://hl7-fhir.github.io/history.html

目前有两种版本的FHIR。第一个是DSTU1。这是SVN(“dstu1”)中的一个分支，仅针对重要的错误报告进行了更改。此处的参考实现得以维护并向后兼容。第二个版本是主干版本，我们正在其中准备第二个DSTU版本。 svn目前非常不稳定-不断变化，有时我们会多次撤消变化，因为我们考虑了委员会中的各种选择。此外，DSTU1和干线之间存在一些重大的突破性变化，并且还会有更多变化。因此，您不应该期望DSTU1和中继之间的切换会很轻松。实施者也不应使用主干，除非他们确实处于边缘状态(并且紧密连接，例如实施者通过Skype通道)。当主干稳定后，我们认为值得发布实施者beta，我们更新版本和版本历史记录，并在此处发布:http://hl7.org/implement/standards/FHIR-Develop/并发布该版本的maven软件包。

在主干中，由于进行了许多更改，因此我们还将常量更改为大写，并翻转了生成获取/设置属性的方式。同意这是有代价的，但是从DSTU1切换到中继已经要付出代价。当我进行beta版发布时(实际上很快)，我将更新Java参考实现编号等。请注意，Java常量使用了大写形式，但是有线格式常量没有更改，因此存储的json流很好(尽管它们被规范中的许多其他更改破坏了)

考虑到DSTU 1和主干之间的更改范围(尚无这些更改的列表，我必须准备在更新Beta时使用)，您应该期望对转换进行大量的修改。目前，我维护一个为这两个服务器实现服务器的单一源(在Pascal中，http://github.com/grahamegrieve/fhirserver)，但是我怀疑这种方法将被NewBundle表示的更改所破坏。

因此，具体答案为:

0.0.8x代码行的用途是什么？它的目标用户是谁？

现有DSTU1规范的支持用户

干线代码的目的是什么？它的目标用户是谁？

准备成为DSTU2。它应该在几周后变得更加稳定-一旦我们开始进行向后不兼容的更改，我们现在正在尝试完成尽可能多的更改

是否会期望0.0.8x的用户迁移到主干代码库？

是的，当DSTU 2发布时，或者至少在我们开始在主干版本上为DSTU2做准备的连接马拉松时(第一个计划于1月发布)

如果是这样，将使用哪种迁移策略来解决代码库之间的许多不兼容性？

将会有很多重写代码。我们可能会发布xml转换，以便在定稿完成后将资源从DSTU1迁移到DSTU2，但这甚至是不可能的

4a。每个代码库中的代码弃用策略是什么？

DSTU 1非常保守。尽管我们永远不能保证稳定性，但主干将会安定下来。 Beta版本将是这些版本的及时发布。

在主干的代码中，从修订到修订，可以期望什么水平的向后兼容性？

目前没有，真的。

是否有FHIR路线图可供系统开发人员用来计划自己的开发周期？

好吧，除了上面提到的版本策略外，还有: http://www.healthintersections.com.au/?p=2234(适合您，不是吗？)