语义版本控制＆amp;持续部署

Question

墨菲大约一个小时前踢了我的一个。

上下文：

我最近加入了一个新的雇主，产品在依赖关系方面已经过时了，Angular 1.2.x，Angular-UI 0.12.0等......

这是我工作过的第一个雇主，每天都会按照生产方式进行生产等等（前提是我只能在所谓的大型公司工作，转弯速度慢得多）部分我的初期任务是尽我所能升级依赖项。因此，今天早上我们与一些开发者进行了一次关于为什么我们所有的bower依赖关系都被硬编码到特定版本的watercooler谈话。

这两种思想流派是：

• 硬编码版本显然提供100％的安全性，因为版本无法动态跳转，但缺点是如果有人没有主动更新，我们会再次落后。
• 我认为语义版本控制为我们提供了某种形式的安全性（加上具有多个登台环境），并且它应该足够好，比如说Angular设置为^1.5.9

引自语义版文档：

  

次要版本Y（x.Y.z | x> 0）必须递增，如果是新的，则向后   兼容的功能被引入到公共API中。肯定是   如果任何公共API功能标记为已弃用，则递增。   如果有大量新功能或改进，它可能会增加   在私人代码中引入。它可能包括补丁级别   变化。当次要版本时，补丁版本必须重置为0   递增。

问题：

今天早上我们部署到舞台上，一切似乎都很好，然后我们在大约一个小时前部署到制作中......并且...... BOOM

问题是AngularJs从1.5.9变为1.6.0。我已经在迁移文档（migrate 1.5 -> 1.6）中看到过这一点：

  

您可能还会注意到此版本的发布时间比平时要长   突破性变化列表。不过，不要让这让你灰心丧气   他们中的大多数都很小 - 通常不会影响真实   应用。这些重大变化对于：

是必要的

问题：

我的断开连接在哪里？ ......或者说语义版本只是我一直以来的虚假安全感吗？

人们如何处理这些情况？人们是否在任何现实世界的解决方案中使用自动依赖性升级（对不起，如果对某些人来说这是非常明显的话），对我来说，构建通过分期，并且生产中断实际上更令人担忧。

（我之所以提出这个问题的原因是因为对小额增量更新的恐惧现在又回来了，并且比以往任何时候都更强大，而且我不确定我是否同意这一切的情绪。 。）

Answer 1

看起来很简单，如果他们做出重大改变，他们应该把它提升到2.0.0。他们没有进行语义版本控制。并非所有项目都使用X.Y.Z.样式版本正在进行语义版本控制。

试着了解这是怎么回事＃＆＃34;繁荣＆＃34;在测试和登台环境中以自动方式。不能害怕前进，必须在某个时候完成，而且我宁愿一步一步地进行，而不是像完全手动的过程一样，推动许多版本。 / p>