【发布时间】：2013-04-27 17:41:18
【问题描述】：
情况：
我们的首席架构师创建了一个 C++ 库，旨在作为我们工作领域的“运行时”（它们实际上是几个库 - 想想 sdl、sdl_net、sdl_ttf，但是具有 C++ 接口，并且它们总是应该一起使用，即使您可能只需要其中一个）。
也就是说，这些库链接到一堆 CRUD 应用程序、其他（更具体的）库（想想基于 sdl 的 sprite 库）和更大规模的应用程序（客户端/服务器、远程 GUI）。
问题：
由于很多原因（当然，时间不够，就是其中之一），“运行时”库仍然会发生变化。可能会引入新类，可能会将现有类拉入类层次结构，可能会更改方法参数等等。由于没有 ABI，链接运行时的代码会中断，并且在没有正确版本控制的情况下动态链接时，生产软件会崩溃。
拒绝的解决方案：
- 运行时库的更改应引入新版本。在发布
myrt.so.2时，链接到myrt.so.1的二进制文件仍然有效，因为不打算删除myrt.so.1（在一段时间内）。
拒绝理由：会有很多新的库版本“污染”生产环境。最坏的情况是每个二进制文件都有自己的myrt 版本。
- 静态链接。
拒绝的原因：加上明显的膨胀，上面的最后一个陈述实际上也适用于此。
- 可能保留两个
myrt版本并重建依赖关系，否则在发布myrt的新版本时会中断。
拒绝的原因：没有时间测试所有依赖项的功能（只有很少的自动测试）并且发布未经测试的二进制文件的风险被认为太高。
问题：
我们还能做什么？您是否认为有任何方法可以通过处理拒绝声明来恢复提议的解决方案之一？
这可能是在纠正症状而不是原因（缺乏自动测试、缺乏实际创建稳定 API 的资源等）。老实说，我没有看到解决更大问题的方法，尽管已经采取了更好的测试步骤。
【问题讨论】：
-
选项#0：解雇首席架构师？
-
如何对片段进行版本控制而不是对整个库进行版本控制？例如，如果需要更改层次结构，请创建一个新类而不是更改旧类。
-
@VaughnCato：说得好。然而，可悲的是，我在一个子条款中暗示了这一点 - 更清楚地说：版本化这些片段并且只发送一个相应的片段也被拒绝（“这些库形成一个单元，但共享对象/DLL是为了清晰度/文件组织”）。
-
如果静态链接不是一个选项，那么任何被修改的 API 部分都可能会破坏某些东西。所以唯一真正的选择是不修改 API。但是，如果您扩展 API，它应该仍然可以。例如，不要向现有类添加新成员，创建从旧类派生的新类。不要替换类方法，添加新方法等。
-
@VaughnCato 所以我建议在保持二进制兼容性的同时更改框架（例如，不要触摸标题，避免以会破坏 bc 的方式更改结构）。无论如何，当进行广泛的测试时，也许在每个发布周期都基于这些“黑客”进行重构。收到回复后更新。
标签： c++ shared-libraries versioning project-organization