从1500年代末开始，你开始看到一种趋势出现在当时的大地产上。庄园的许多领主会建造异想天开或奢侈和典型的无用建筑，作为转换件或装饰景观。他们被称为愚蠢的事威克洛郡Powerscort Gardens的胡椒壶塔，爱尔兰。一些最愚蠢的是假遗址，它假装是旧建筑的遗迹，但实际上是在那种状态下建造的（例如，埃蒙诺维尔的哲学圣殿）。每次有人提出语义版本，我都会想起这些愚蠢。现在别误会我，我喜欢语义版本化提供的象牙塔理想我们。那个如果只有向后兼容的大修补程序介绍了。那个如果向公共api引入了新的向后兼容功能，则次要版本必须递增。如果有任何向后不兼容的更改，则主版本必须递增向公众介绍阿皮。真可爱. 很 完美。这可能有什么问题？首先是真实世界…我们依靠人类来决定版本编号。人类会犯错。很容易出错，并且以非向后兼容的方式更改方法签名。一旦你发现2.4.5实际上并不是2.4.4的替代品，只是做了一些小的错误修复，而且应该被称为3.0.0，你的信任就消失了。你不会相信你所依赖的项目能够理解语义版本控制，而你又回到了过去好吧。什么我听到你在打电话吗？执行语义版本控制的工具？嗯，是的，一个吸引人的警笛召唤是工具解决方案。特别是在Java中，我们可以使用字节码分析。我们下载工件的前一个版本，并比较两者的字节码，以确保公共API类签名只会以向后兼容的方式发生变化，除非主版本号已经更改。如果公共API没有变化，我们允许次要版本保持不变。太棒了。我喜欢那个工具。很有帮助。但是仍然不能保证语义版本控制的遵从性。在版本2.4.4new FooBuilder（）.withoutBar（）.build（）起作用是因为你可以在实现中构建一个没有条的Foo，但是在2.4.5中，你只能构建一个没有条的Foo，如果它有一个满语，sonew FooBuilder（）.withoutBar（）.withmanish（manish）.build（）的工作原理与doesnew FooBuilder（）.withmanish（manish）.withoutBar（）.build（）只有我的代码没有写的好吧。去吧更直白地说，公共API不仅仅是类和方法签名，而是这些类和方法允许的使用模式。如果一个API现在要求您从同一个线程调用一组方法，或者在对其他资源持有锁的情况下，这是一个逆向的改变。工具不能帮助你抓住这些改变了。所以是的，工具很好，但它不能解决问题，也就是说，我们让人编写代码，由人决定下一个版本号是什么，人类制造错误。那么有市场营销…开发人员想要使用的版本号与市场营销想要使用的版本号完全没有关系。看看微软Windows:版本号Release5.0Windows20005.1Windows XP5.2Windows XP 64位编辑5.2Windows Server 20036.0Windows Vista6.0Windows Server 20086.1Windows Server 2008 R26.1Windows 76.2Windows 20126.2Windows 8这是什么？你有一个简单的解决方案吗？我们让市场部根据他们想要的效果来命名它，我们会称之为内部版本号，我们知道它应该是什么样的！嗯，是的，另一个吸引人的警笛在召唤。你想知道是什么问题吗？我有一个非常简单的例子：我必须去查找Windows市场营销版本到版本号的映射，才能得到上表。现在对于类似操作系统的东西来说，这不是什么大问题，但是当你深入到依赖地狱，你必须从问题追踪器下拉列表中选择FooBar Ultra Pro 2012.7，以便提交一份针对FooBar 2.4.3的支持罚单，告诉他们在与Manish 7R2（也称为Manish 7R2）一起使用时存在问题满语：5.3.9你可能开始感到痛。在作为我以前的雇主，我们在墙上挂了一张很大的A0表，上面有组成不同产品线的所有组件的每个支持版本。当你达到那种疯狂的程度，你就会知道错了。终于，在JVM上，有类路径……任何不在JVM上的人，动态库的链接时间问题都很严重，尽管静态链接有时会让你出狱，但它只能工作这么长时间……这个问题会伴随着版本的重大变化而出现。一旦你做了一个重大的版本变更，你就在说我不再保证旧的API甚至存在，更不用说表现得和beforeWell一样好，但是如果你不同时改变你的API的名称空间，那么任何使用依赖旧版本API的第三方代码的人都会死在水里。它们的代码需要新的API，同时也需要旧版本的API。这就是最终的依赖见鬼，换衣服命名空间允许两个版本共存……但这也意味着每个人都很难接受新的版本……而且您可能会被迫支持两个版本：一个是您想要支持的版本，另一个是您不想支持的版本，它是丑陋的旧版本API。所以这是否意味着语义版本控制是无用的？不。这实际上是一个崇高的目标。一个我们都应该追求的理想。记住，你永远不会达到那个目标。你会使错误。不你投入的工具或过程的数量将防止你犯下的错误，所以当你把工具或过程放在适当的地方时，一定要评估它真正给你带来的收益和它带来的痛苦。例如，使用工具根据以前的版本验证公共API的字节码更改，如果操作正确，是快速且容易获得的结果……因此，将其添加到您的构建中是很好的……您可能不希望每次生成都使用它，而只希望在发布之前或在CI生成服务器运行时进行飞行前检查。另一方面，要求对所有更改的代码路径进行代码复查，在这种情况下，对每一行更改的代码进行影响评估，这可能不是您希望为每个项目引入的过程……（不过，我希望JVM运行时库也能这样做；-)但在公共API中破坏更改的风险非常高）希望这能让您思考，希望你能开始在你自己的项目中使用语义版本控制中的一些最佳实践……但是如果你认为我会信任一个版本范围而不是语义版本，让机器自动决定我的代码将使用的第三方依赖的版本……你错得很惨。版本范围是一个提示，让人们知道在手动指定要使用的版本时应该考虑的范围cloudbees.com斯蒂芬康诺利有超过20年的软件开发经验。他参与了许多开源项目，包括Jenkins。Stephen是Jenkins项目的首批非Sun成员之一，他开发了天气图标。斯蒂芬住在爱尔兰都柏林，那里的天气图标特别有用。在Twitter和他的博客上关注斯蒂芬。