node.js - 语义版本控制和持续部署

Question

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

上下文:

我最近加入了一家新雇主，该产品在依赖项方面相当过时，Angular 1.2.x、Angular-UI 0.12.0 等......

这是我工作过的第一个每天进行生产等构建的雇主。(以前我只在所谓的大型公司工作过，周转速度要慢得多)我最初的任务的一部分是尽可能升级依赖项。因此，今天早上早些时候，我们与一些开发人员进行了一次饮水机谈话，讨论了为什么我们所有的 Bower 依赖项都被硬编码为特定版本。

这两种思想流派是:

• 硬编码版本显然可以提供 100% 的安全性，因为版本无法动态跳转，但缺点是如果有人不主动更新，我们将再次落后。
• 我认为语义版本控制为我们提供了某种形式的安全性(再加上拥有多个暂存环境)，并且它应该足以让 Angular 设置为 ^1.5.9。

引自语义版本文档:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

问题:

今天早上早些时候，我们部署到了暂存阶段，一切看起来都很顺利，然后我们在一小时左右前部署到了生产环境，然后……繁荣

问题是 AngularJs 从 1.5.9 更改为 1.6.0。我在迁移文档 ( migrate 1.5 -> 1.6 ) 中看到这一点已被注意到:

You may also notice that this release comes with a longer-than-usual list of breaking changes. Don't let this dishearten you though, since most of them are pretty minor - often not expected to affect real applications. These breaking changes were necessary in order to:

问题:

我的断线在哪里？ ...或者语义版本文档只是我一直以来的一种错误的安全感？

人们如何处理这些情况？人们是否在任何现实世界的解决方案中使用自动依赖升级(请原谅，如果这对某些人来说非常明显)，对我来说，构建通过了暂存阶段并在生产中中断的事实实际上更令人担忧。

(我问这个问题的原因是因为对小增量更新的恐惧现在又回来了，而且比以往任何时候都更加强烈，我不确定我是否同意这一切的情绪......)

Answer 1

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

尝试了解它是如何在您的测试和登台环境中以自动化方式“繁荣”的。不能害怕前进，它必须在某个时候完成，我宁愿更频繁地一步步移动，也不愿像完全手动过程那样突然升级许多版本。