1
我们的首席设计师创造++库，它的目的是作为一个“运行”为我们工作的领域（他们真的是几个库一个C - 认为sdl，sdl_net，sdl_ttf，但是有一个C++接口，并且它们总是应该被完全使用，即使你可能只需要其中的一个）。也就是说，这些库链接到一堆CRUD应用程序，其他（更具体）库（考虑基于sdl的sprite库）以及更大规模的应用程序（客户端/服务器，远程GUI）。
问题：
由于一堆理由（当然，没有时间，是其中之一）的“运行”库仍可能发生变化。可能会引入新的类，现有类可能会被拉入类层次，方法参数可能会发生变化等等。由于没有ABI，链接运行时的代码将中断，并且生成软件在动态链接时会崩溃而没有正确的版本控制。
拒绝解决方案：
- 变更运行时刻库应该推出一个新版本。链接到
myrt.so.1的二进制文件在myrt.so.2发货时仍然有效，因为myrt.so.1不打算被删除（一段时间）。
Reson for rejection：会有很多新的库版本“污染”生产环境。最坏的情况是每个二进制文件都有自己的myrt版本。
- 静态链接。
拒绝的理由：加上明显的膨胀，上面的最后一个陈述实际上也适用于这里。
- 保持也许两个
myrt版本和重建出货的myrt新安装时可能会违反相关性。
拒绝原因：没有时间来测试所有依赖项的功能（只有很少的自动测试），并且发送未经测试的二进制文件的风险被认为太高。
问题：
我们还有什么可以做的？您是否看到通过处理拒绝声明来恢复提议的解决方案的方法？
这可能是医治症状而不是原因（缺乏自动测试，缺乏实际创建稳定API的资源等）。老实说，尽管采取了更好的测试方法，但我没有看到更大的问题。
选项＃0：火总设计师？ – 2013-04-27 17:44:45
如何对版本进行版本控制而不是对整个库进行版本控制？例如，如果需要更改层次结构，请创建一个新类而不是更改旧类。 – 2013-04-27 17:47:26
@VaughnCato：好点。然而令人遗憾的是，我在一个子条款中暗示了这一点 - 要更清楚一点：版本化这些作品并且只发送一个作品也被拒绝（“这些图书馆形成一个单元，但共享对象/ DLL是为了清晰度/文件组织“）。 – msi 2013-04-27 17:53:22