作为系统实现者，当我们从一个版本的FHIR迁移到下一个版本时，我们将面临两难选择。我们开始使用FHIR 0.0.81，然后在2014年9月10日转移到SVN修订版2833，以修复错误。根据建议，我们从SVN中继下载了Java代码，并按照FHIR Build Process page上的说明进行操作。
现在FHIR 0.0.82可用，我们希望升级到已发布的版本。然而，在下载0.0.82之后，我们注意到在主干rev2833中的几个资源（例如约会）不在0.0.82版本中。这导致了我们的第一个问题：
如果主干不包含发往下一个版本的最新代码，那么主干包含什么？
是否有人会使用行李箱中的内容？
是否有创建0.0.82的发布分支？
由于我们的代码依赖于在trunk上引入但未包含在0.0.82中的资源，我们必须继续直接从SVN签出FHIR。 2014年10月21日，我们下载了SVN修订版3218 Java代码。当我们将该代码集成到我们的系统中时，我们发现了许多兼容性问题以下是其中一些：
各种枚举值从小写变为大写，包括 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”这样简单的操作需要迁移实用程序来更新现有数据库内容。
我们正在大力投资FHIR;我们希望它成功并被广泛采用作为标准。为了实现这一点，需要解决向后兼容性和版本迁移问题。在那种徒劳的情况下，任何可以解决下一个问题的光都会让我们前进：
0.0.8x代码行的目的是什么？谁是目标用户？
中继代码的目的是什么？谁是目标用户？
是否需要0.0.8x的用户迁移到中继代码库？
每个代码库中代码的弃用策略是什么？
中继代码中从修订版到修订版可以达到什么级别的向后兼容性？
系统开发人员是否可以使用FHIR路线图来规划自己的开发周期？
谢谢， Rich C
答案 0 :(得分：3)
我很抱歉没有记录版本控制对Java参考实现的影响。我会这样做的。我将假设您熟悉版本控制策略：http://hl7-fhir.github.io/history.html
目前有两种版本的FHIR存在。第一个是DSTU 1.这是SVN中的一个分支（＆＃34; dstu1＆＃34;），仅针对重要的错误报告进行了更改。那里的参考实现是保持和向后兼容的。第二个版本是主干版本，我们正在准备第二个DSTU版本。 svn目前非常不稳定 - 不断变化，我们有时会多次扭转变化，因为我们考虑委员会的各种选择。此外，DSTU1和主干之间存在一些大的突破性变化，并且还会有更多变化。因此，您不应期望DSTU1和主干之间的切换将是无痛的。实施者也不应该使用主干，除非他们真的出血（并且紧密连接，例如实施者skype频道）。当主干稳定，并且我们认为它值得发布实施者测试版时，我们会更新版本和版本历史记录，并在此处发布一个版本：http://hl7.org/implement/standards/FHIR-Develop/并发布该版本的maven包。
在主干中，由于进行了许多更改，我们还将常量更改为大写，并翻转了生成get / set属性的方式。同意这有价格，但是从DSTU1切换到主干已经付出了代价。当我发布测试版（很快，实际上）时，我将更新Java参考实现编号等等。请注意，Java常量变为大写，但是线格式常量没有改变，因此存储的json流很好（尽管它们被规范中的许多其他更改打破）
鉴于DSTU 1和主干之间的变化范围（目前还没有这些变化的列表，我将不得不准备当我更新测试版时），您应该期望对过渡进行大量的返工。目前，我维护了一个为两者实现服务器的源代码（在Pascal中，http://github.com/grahamegrieve/fhirserver）但我怀疑这种方法即将被NewBundle所代表的更改打破。
所以，具体答案：
支持现有DSTU1规范的用户
准备成为DSTU 2.它应该在几周内开始变得更加稳定 - 一旦我们开始做出倒退不兼容的变化，我们就会尽可能多地完成这些变更
是的，当DSTU 2发布时，或者至少，当我们开始在准备DSTU2的主干版本上使用connectathons时（第一个计划在1月份）
将会有很多重写代码。我们可能会发布xml转换，以便在资源完成时将资源从DSTU1迁移到DSTU2，但这可能是不可能的
4A。每个代码库中代码的弃用策略是什么？
DSTU 1非常保守。行李箱将落户，但我们永远不会保证稳定。测试版将是这些版本的即时版本。
没有，真的，此刻。
嗯，除了上面引用的版本政策之外，还有：http://www.healthintersections.com.au/?p=2234（适合你，不是吗？）
答案 1 :(得分：0)
作为Grahame回复的补充：在规范的“文档”标签上，只有一个粗体链接 - Read Prior to Use。该页面试图表明DSTU版本既不向前兼容，也不向后兼容。它不能--DSTU的全部目的是收集实施反馈，以便在我们采用规范性措施时使标准准备好被锁定。如果我们承诺在DSTU中向前和向后兼容，那么我们将坚持在初始草案期间做出的任何决定，无论它们是否是好的。