我有一组程序，每个程序都有自己的版本。所有这些程序都依赖于一个库，同样也有它自己的版本。例如依赖于库的程序版本控制
Foo-1.0.3
Bar-2.1.5
Baz-1.3.4
它们取决于libfrobniz-1.4.5。恰巧我必须对图书馆进行一次重大改革（涉及许多重构）。这意味着它会打破一切（Foo，Bar and Baz）。当然，由于这是一个主要的和落后的不兼容的返工，图书馆将会碰到libfrobniz-2.0.0。
我的问题是关于Foo Bar和Baz的版本。我将升级它们以使用libfrobniz-2.0.0，但我没有改变它们的功能。这三个程序的新版本可以像旧版一样使用，因此它们完全兼容。但是，它们将依赖于libfrobniz的完全不同版本。你会建议打他们的版本主要数字，或只是补丁程度？
请记住，更改依赖关系的主要编号是最终用户的主要变化。这绝对不是补丁程序级别，除非你有一个非常好的理由，否则我会说坚持专业。
如果依赖库暴露了已更改库中的类型，那么最终用户肯定会发生重大变化。也许不是没有暴露的东西？ – 2009-08-16 22:06:54
不，没有任何libfrobniz暴露给最终用户。 – 2009-08-16 22:07:54
确实这种改变类似于重构。我只更改内部（内部是整个库），但没有任何最终的软件功能以任何方式被触及或改变。 – 2009-08-16 22:10:24
我会保留Foo，Bar和Baz的版本号相同。由于您没有向这些面向用户的产品推出新功能或错误修复，因此不需要打扰版本号。此外，如果您决定修改版本号，可能会导致用户混淆。您的用户可能会疑惑为什么您的产品具有新版本的版本号，而没有任何新的记录功能或缺陷修复程序。
在三个面向用户的应用程序中，您可以有一个窗格/窗口，指出产品依赖于libfrobniz并且已升级。
您的版本控制方案取决于您的业务和技术需求。
一些公司每年都会发布“重大”升级以获得关注和升级的一些收入。他们中的一些人仍然发布测试版，直到对软件质量满意为止。
准备你自己的计划，让你的客户知道它。 通常，第一个字母是主要版本的主要版本，然后用于改进，然后用于构建和补丁。
这不就是建立一个32位和64位版本的库相同吗？ 32位取决于32位库，而64位取决于64位库。
按照你会使用类似的东西
规则“当然，因为这是一个重大的和不向后兼容返工，”
我想起了当年的客户不得不把所有的力量他们的软件供应商即将破产，如果该软件供应商有勇气打破向后兼容性，拒绝花费任何金钱，直到向后兼容性恢复。
软件供应商一直承认。
今天，他们似乎可以做任何他们想做的事，而每一位顾客都会盲目追随他们，有点像来自“1984”的最低阶层人士。
但或许我过分悲观。
编辑
有人指出的情况下，只有一个客户，我自己。在这种情况下，我不希望有任何需要“版本控制”。这样的客户只对一件事情感兴趣：软件可以工作，并且对一个单一版本感兴趣：据说与他最新的规格相符。
你知道，有些情况下你自己只有一个客户。 – 2009-08-16 22:02:59
回应您的编辑。不是真的。我需要对我使用的内容进行版本控制，因为如果在三年内，我必须重新计算内容，我必须知道我用来生成该结果的软件版本。 – 2010-02-23 10:49:18
不是一个笨蛋。您建议的帖子将讨论版本控制的具体风格。我在寻求一般规则，并关注我的具体问题。 – 2009-08-16 21:58:25
@Stafano：好吧，这可能是一个骗局，但不是我发布的那个骗局。 – 2009-08-16 22:04:11
针对我的具体问题重做了这个问题，这正是我现在所关心的问题。 – 2009-08-16 22:04:56