Underscore: 下划线不跟随 SemVer

引用https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249：

谢谢，但严格遵循“语义”版本控制对于 Backbone 来说效果不佳。 鉴于该项目几乎是所有表面区域，并且内部结构非常少，几乎所有对 Backbone 的给定更改（补丁、拉取请求）都会以某种小方式破坏向后兼容性……即使只是对于那些依赖先前未定义行为的人。

其余的评论也值得一读，即使你不同意。

https://github.com/jashkenas/coffeescript/issues/3352#issuecomment -34217211

@akre54我很好奇您对 Lo-Dash（Underscore 替代方案）和 ExosJS（Backbone 替代方案）等其他项目可以遵循 semver 的想法是什么？

既然那些插入式替代品_可以跟随 semver_，那不是在 Underscore/Backbone 核心推动的借口中扔扳手吗？

夫妇的事情。

在大多数情况下，Lo-Dash 坚持由 Underscore 铺就的牛路，因此它具有推迟到 Underscore 发布以推动版本提升以实现功能均等的优势。 与 Underscore 的区别往往更多的是在增强类别中，而在重大的重大更改方面则较少。

Lo-Dash 以代码混乱为代价为 bc 添加了更多的保护代码，而 Underscore 则力求简洁。 当库开始较大时，更容易摆脱几行额外代码（Lo-Dash 时钟为 8.7k 行，而 Underscore 为 1.4k。）还有更多的内部垃圾可以在 Lo 中完成。破折号，因为很多逻辑都是内部的。

它也是由一个贡献者（你）不成比例地编写的，而 Underscore 的更改往往来自一组更加多样化的贡献者，这意味着新功能可能随时出现，有时大的功能更改和向后不兼容的更改出现在不合时宜的时刻发布时间表。

有趣的是，我觉得 Underscore 也有发布计划的缺点，即在比 Lo-Dash 更多的初学者项目中使用（就其本质而言，Lo-Dash 往往会吸引需要它的力量的开发人员）。 更高级的开发人员会更自如地处理重大更改的后果，并且可能会更了解他们的推理。

最后，作为 Exoskeleton 的合著者和主要贡献者，我将第一个告诉你我们也没有关注 semver。 如上所述，我们还具有 Lo-Dash 的优势。

在大多数情况下，Lo-Dash 坚持由 Underscore 铺就的牛路，因此它具有推迟到 Underscore 发布以推动版本提升以实现功能均等的优势。 与 Underscore 的区别往往更多的是在增强类别中，而在重大的重大更改方面则较少。

这与 Underscore 的版本策略有什么关系？ Lo-Dash 在 semver 之后会增加版本，这就是为什么它在 v2.x 上继续在 v3.x 上的原因。

Lo-Dash 以代码混乱为代价为 bc 添加了更多的保护代码，而 Underscore 则力求简洁。

保护代码或简洁与版本策略有什么关系？

当库开始较大时，更容易摆脱几行额外的代码（Lo-Dash 的时钟为 8.7k 行，而 Underscore 为 1.4k。）

Lo-Dash 有内联文档，LOC 与版本无关。

在 Lo-Dash 中还可以完成更多的内部处理，因为很多逻辑都是内部的。

下划线不能说同样的话吗？

它也是由一个贡献者（你）不成比例地编写的，而 Underscore 的更改往往来自一组更加多样化的贡献者，这意味着新功能可能随时出现，有时大的功能更改和向后不兼容的更改出现在不合时宜的时刻发布时间表。

这就是 Underscore 让维护者接受/拒绝或推迟到未来版本的原因。
同样，与版本控制无关。

有趣的是，我觉得 Underscore 也有一个缺点，即与 Lo-Dash 相比，它被用于更多的初学者项目（就其本质而言，Lo-Dash 往往会吸引需要其强大功能的开发人员）。

我不同意，Lo-Dash 有成千上万的家属，而且所有人都不能成为它的专家。

更高级的开发人员会更自如地处理重大更改的后果，并且可能会更了解他们的推理。

因为 Lo-Dash 遵循 semver 开发人员在跳转到主要版本更新之前不必处理后果。 与 Underscore 不同，Lo-Dash 不会从他们的脚下改变，因为他们使用~作为包的版本范围。

最后，作为 Exoskeleton 的合著者和主要贡献者，我将第一个告诉你我们也没有关注 semver。

然后你应该把它从它的营销中删除。

我认为 Underscore 没有任何理由不能遵循 semver。
不遵循它对您的用户是一种伤害：皱眉：

如果您想加入 npm 或 bower，则无需讨论。 您必须使用 semver。 你正在做出一个隐含的承诺来遵循 semver，如果你不这样做，就会在没有警告的情况下破坏人们的代码，而且几乎每个人都不赞成。

我们正在谈论破坏生产代码的选择。 用别人的时间和金钱玩一个马虎的游戏并不酷。

这意味着您的版本号会更快地变大。 所以呢？ 这是一个数字。 这比破坏某人的生产购物车要好得多。

+1 为服务器

就个人而言，我认为在错误报告中获得_personal_ 并不“酷”。 它要么遵循语义版本控制，要么不遵循语义版本控制。 以下是原因——砰、砰、砰——为什么它会成为一个更好的图书馆。 以下是原因——砰，砰——为什么维护者可以以与 semver 一致的方式增加版本号。

之后，由维护者决定。 如果您不同意他们的立场，可以使用其他库。您可以分叉该项目（就像其他人所做的那样）。 您可以随心所欲地撰写博客文章。

但是，让我们尝试产生民事分歧。

我不明白@raganwald。 谁有私心？

我不攻击任何人。 我指出 semver 是您在将包发布到 npm 或 bower 时签订的 API 合同的一部分。

如果您违反了该合同，那么您就破坏了其他人的代码。 这不酷。

npm 工作得非常好，因为我们都同意一些规则，使我们的模块能够很好地相互工作。 如果你打破了这些规则，你就会破坏其他试图与你的模块一起工作的模块。 您破坏了依赖您的代码的生产应用程序。

问题不是“我们应该使用 semver 吗？” 问题是，“我们想成为这个生态系统中的好公民吗？”

关键是在像 Underscore 这样的项目中，_每一个_变化都会对某人造成破坏。 如果我们从_.extend中删除一个空保护（使用随机示例），因为它会导致某人出现错误，并且会为其他人创建错误，那是补丁吗？ 是小版本吗？ 主要的？

对于Underscore 和Backbone，我不认为固定你的依赖是不合理的。 遵循 semver 不是发布到打包程序的要求。

关键是，在像 Underscore 这样的项目中，每一次更改都会对某人造成破坏。

你跳到一个极端来证明你的立场。 事实是，这是一种平衡。 有流行的 API、边缘案例和记录在案的行为。 通过简单地修复错误和添加功能，很可能会在一段时间内不影响主要版本。

这意味着维护者必须思考和计划。 这意味着您可能必须为在不破坏反向兼容性的情况下无法解决的功能或更改创建路线图，这很好。

Underscore 增加了补丁版本并引入了重大的重大更改。 这是维护者可以完全控制的事情。

对于Underscore 和Backbone，我不认为固定你的依赖是不合理的。

文档中肯定应该有消息/警告。

@akre54更改 _undocumented_ 功能或 _undocumented bugs_ 可能会破坏依赖这些功能的代码，但用户依赖未记录的功能和 bug 后果自负。

忽略 semver 会使您的 API 的_每个用户_都处于危险之中。 人们在一直遵循 semver 的大型开源项目中修复错误，但_在 npm 生态系统中很少看到大版本号_。

这是为什么？

因为_所有好的 API 都遵循开放/封闭原则_（对扩展开放，对中断更改关闭）尽可能地接近，以便用户可以跟上 API 的步伐，并且更改不会破坏现有代码。

为了增加轶事，我的代码过去也被下划线颠簸破坏。 我们采取了承诺node_modules来阻止它，因为--save --save-exact没有削减它。 如果二级依赖依赖下划线并使用^x.y.z版本，那么您的应用程序仍然损坏。

至于表示进度的版本号，我不在乎。 使用版本 2.1.3 或 143.3.2 对我没有任何影响。 库的进度和成熟度不以版本号衡量。 我只是不想在周日下午打电话，因为有人更新了依赖underscore@^x.y.z的依赖项。

:thumbup: 是的。 @braddunbar提出了一个我还没有提到的观点——忽略 semver 会使你的包成为一个危险的、有毒的包，因为这种重大变化可能会在_任何地方_挥之不去。

强制用户根据您损坏的软件包查找第三方代码中的中断绝对是一项繁重的要求。

IMO，真正的图书馆进步和成熟度是用可靠性来衡量的，而 semver 在实现这一目标方面还有很长的路要走。

当然，文档中应该有一条消息。

确实。 如果这是我们的决定，我很乐意添加一个。

我并不反对更好的发布系统（上帝知道等待几个月才能部署一个小错误修复是一件痛苦的事），但我不确定“follow semver”是_the_一个正确答案。

现在，我认为它是否是一个正确的答案并不重要。 它_是_社区接受的答案。

我认为没有人说“follow semver”是更好的发布系统的正确答案。 我们说的是 npm API 合约，违反该合约会造成损害。

@jdalton和@dilvie你建议我们如何处理版本？ 接受功能怎么样？ “使用 semver”并没有真正告诉我们任何事情。

我们是否应该将_.matches之类的功能推迟几个月，以便我们可以等待当前代码的错误修复，还是应该现在发布它并让人们敲定实现问题？

我认为 semver 只是在这里并不完全适用。

无耻的自我推销：使用 next-update https://github.com/bahmutov/next-update先测试是否可以在不破坏项目的情况下更新依赖项。 尽管更改*.*.x ，但我不断发现不同模块中的重大更改，所以现在我不信任任何自我声明的版本。

你认为这个项目是一片雪花吗？ Lo-Dash 基本上是 Underscore++，对于@jdalton 来说，跟随 semver 是没有问题的。

接受新功能：

它会破坏现有的 API 合同吗？

是的？ - 碰撞主要版本号。
不？ - 碰撞次要版本号。

接受错误修复/小补丁：

它会破坏现有的 API 合同吗？

是的？ - 碰撞主要版本号。
不？ - 凹凸补丁版本号。

您选择如何安排正式发布完全取决于您。 只需确保版本控制与 semver 兼容，这样您就不会破坏其他人的代码。

同意@dilvie ，例如https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0可能应该是一个重大的突破，因为我们放弃了对稀疏数组的支持。 下一个版本应该是一个重大突破，因为我们将通过lookupIterator添加大量新糖并删除原生迭代器。

如果一个函数的文档必须改变它显然是一个重大的改变

今年我在 JSconf 上对此进行了简短的讨论。 我没有时间在这里详细介绍，但是：

停止将面向人类的“版本控制”与面向计算机（或者实际上是面向构建系统）的“API 兼容性”混为一谈。 停下来。

版本：“我喜欢的这个东西有新功能，或者我有时间时应该感兴趣的其他东西。” 有一个新的 iPhone。 有一个新的 OS X。有一个新的 Ember。 有一份关于算法语言方案的新修订报告。

API 兼容性：“这件事已更新以修复问题，这可能/将打破道路锻炼那个东西。” iPhone的电源插头被更换了。 OS X 不推荐使用资源分叉。 Ember 弃用了一种动作名称样式。 Scheme 现在区分大小写。

后者发生在_during_，或_alongside_，前者； 但前者不一定依赖于后者，甚至与后者无关。 应该跟踪它们，并且（如果我们真的要指定一个版本控制系统，天哪）分别指定。 （在 JS 社区中流行的“语义版本控制”的概念是_特别_迟钝和可怕的；但同样，我不想在其他人的问题评论线程中详细讨论。）

tl;dr：他们不会通过选择自己的道路来破坏你的生态系统。 （_特别是_当这条路有严重缺陷时。）我希望有更多的项目。 去使用别的东西，如果你在它上面弯曲变形。

@elliottcable - 同意面向人类与面向计算机......只要面向人类看起来不像面向计算机的那样，那么合并问题就不会那么严重。

也许将下一个面向人类的版本称为“雪花”而不是 nnn

不过，完全不同意最后一点。 当您假装遵循 API 合同然后违反它时，事情就会破裂。 它花费其他人实时和真正的金钱。 对于像下划线这样受欢迎的项目，可能会造成很多真正的损害。

它会破坏现有的 API 合同吗？

回顾一下这个线程中的第一个参数。 “Underscore 中的所有内容基本上都是表面积”，因此，所有内容，无论是否记录在案，都是其 API 合同的一部分。 任何一次改变都是对每个人的改变。

Lo-Dash 是“Underscore++”，它处理的功能变化几乎没有那么多，因为它可以安全地跟在 Underscore 之后制定主要功能。 Lo-Dash 的改进主要是在底层或添加了一些方法，而不是从根本上重新考虑其功能。

@akre54

你会建议我们如何处理版本？ 接受功能怎么样？ “使用 semver”并没有真正告诉我们任何事情。

您可以接受新的 API 甚至是对现有 API 的一些增强。 如果您添加新的 API 或增强功能（不会破坏兼容性），则它是次要版本更新。

我们是否应该将_.matches之类的功能推迟几个月，以便我们可以等待当前代码的错误修复，还是应该现在发布它并让人们敲定实现问题？

我认为_.matches非常简单。 总会有错误修复。

我认为 semver 只是在这里并不完全适用。

当然可以。 您开始陷入与 semver 不同的发布周期问题，但我会跟随您。

@dilvie ：将避开其余的论点，但把它扔进去：真的，真的很喜欢你关于使用“版本名称”约定的建议。 (=

对于面向人的部分，我非常喜欢less风格的版本控制：

> less --version
less 418
Copyright (C) 1984-2007 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

… 加上一个漂亮的名字，更清楚地表明我们在谈论“有趣”版本，而不是 API 兼容性，并且您已经获得了一个成功的组合。

下划线 42 的 +1： “愚蠢的 Sheltie”。

（至于面向构建系统的部分，我对自动生成的 API 兼容性有一些有争议的观点。请让我们把这些东西从容易犯错的维护者手中拿走，并用静态分析或动态爬取来攻击它。）

@akre54

Lo-Dash 是“Underscore++”，它处理的功能变化几乎没有那么多，因为它可以安全地跟在 Underscore 之后制定主要功能。

那有什么意思？ Lo-Dash 处理_更多更改_，并遵循与下划线分开的自己的版本控制。 Lo-Dash 已经发生了很大的变化，它不得不提供一个与 Underscore 兼容的构建，以继续支持作为替代品。 我们有不同的特性、方法和不同的 API 兼容性问题。

Lo-Dash 的改进主要是在底层或添加了一些方法，而不是从根本上重新考虑其功能。

也不是这样。 Lo-Dash 以更快的速度移动，并且更频繁地与后面的同伴对抗。 这就是为什么我们要使用 ~v2.x 继续 ~v3.x。 Lo-Dash 类似于下划线。 如果 Lo-Dash 可以跟随 semver，Underscore 也可以。 我已经做了~2年了。 你的论点在现实面前简直是一塌糊涂。

我以前也走过这条路，所以我也可以帮助你们到达那里。
对于初学者来说，下一个 Underscore 版本将是一个很棒的 2.0。

我很好奇每个人都认为应该如何定义“重大变革”。 _Every_ 对 Underscore 的新功能更改对其他人来说都是一项重大更改。

让我们以最近对_.each的所有更改为例。 当我们更改_.each的返回值以返回原始列表时，我们是否应该碰撞？ 这是一个错误修正吗？ 新功能？ 向后不兼容的变化？ 它之前返回undefined ，所以它不太可能破坏任何人的代码。

当我们允许内部each帮助器在外部重新分配时，我们是否应该遇到问题？ 这会破坏某人的密码吗？ 那里没有更改公共 API。

更改_.each以避免稀疏数组并使用 for 循环而不是原生forEach显然对某些人来说是破坏性的，但是既然稀疏数组已经死了，谁真的在乎呢？ 我们应该把主要版本推过去吗？ 这是一个错误修正吗？

我认为我们在主要版本的更新上迟到了（在219 次提交中发生了很多事情）。 2.0 版本和我们版本政策的巩固将在这里大有帮助。

@akre54

Underscore 的每一项新功能更改对其他人来说都是一次重大更改。

不必要。

让我们以最近对 _.each 的所有更改为例。 当我们更改 _.each 的返回值以返回原始列表时，我们是否应该碰撞？ 这是一个错误修正吗？

这不是错误修复，而是增强。 它不会破坏吗？-- 这可能是一个安全的更改，因为它不太可能依赖_.each的返回值，并且开发人员报告说在切换到 Lo-Dash 时不会成为障碍。 如果对断裂有疑问，或使用 RC 释放测试水域。 如果更改是允许从_.each提前退出，我会说这是一个明确的突破性更改，因为开发人员在使用 CoffeeScript 时会遇到这种情况。

当我们允许内部每个助手在外部重新分配时，我们是否应该遇到问题？ 这会破坏某人的密码吗？ 那里没有更改公共 API。

我会说这属于未记录的实施细节。 当时这种变化不允许任何新的东西，因为 Underscore 仍然分支为本地方法。 此更改属于 1.6.0 后更大的更改组，因此可以登陆 2.0。

更改_.each以避免稀疏数组并使用 for 循环而不是原生forEach显然对某些人来说是破坏性的，但是既然稀疏数组已经死了，谁真的在乎呢？ 我们应该把主要版本推过去吗？ 这是一个错误修正吗？

它可以被视为一个错误修复，但它绝对是一个突破性的变化。 这是开发人员在切换到 Lo-Dash 时遇到的问题之一。 由于 Underscore 过去的方式，在可用时使用 native，它会掩盖稀疏数组的使用，并且开发人员只有在旧浏览器中测试时才会遇到这个问题。 然而，随着这一变化，开发人员将在现代浏览器中更快地注意到他们的稀疏数组使用，因此他们以前工作的代码有可能会遇到障碍。

我认为我们在主要版本的更新上迟到了（在 219 次提交中发生了很多事情）。 2.0 版本和我们版本政策的巩固将在这里大有帮助。

:+1:

破坏性变化（复数的破坏性变化）

（计算）软件系统某一部分的更改可能导致其他组件发生故障； 最常出现在多个应用程序使用的共享代码库中
“在没有重大更改的情况下无法修复旧条目，因此在导入库中将旧条目重新映射为新条目。”

其中一些需要一些思考和判断。 确实，所有更改都会破坏某人的代码，但如果所有参与者都同意使用开放/封闭原则作为破坏构成的指导，那么每个人的生活都会变得更轻松。

因此，向 API 添加任何属性或方法通常不是重大更改（API 对扩展开放，但对向后不兼容的更改关闭）。

对函数签名的更改需要更多思考。

当我们更改 _.each 的返回值以返回原始列表时，我们是否应该碰撞？

这是 API 的文档化功能，用于某种目的吗？ 例如，当传入的输入不会产生合理的输出时，某些函数会返回 undefined。 each的情况似乎并非如此......所以，可能不会破坏。

另一方面，避免使用稀疏数组更有可能改变开发人员所依赖的返回值，因此很明显，这是一个破坏性的改变，任何使用稀疏数组的人都会关心。

稀疏数组可能无法在 ES6 中存活，但它们还没有消亡。

@akre54
有时，关于变更是否中断的答案并不直截了当。 在这些情况下，上下文、历史和数据会有所帮助。 幸运的是，我能够使用 Lo-Dash 作为新功能的试验场，并查看来自 Underscore 的开发人员会遇到哪些变化。 Underscore 可以反过来使用它来帮助就更改的影响做出明智的决策。

_非常至少_以下 semver 将有助于防止重大的重大更改滑入补丁版本，并鼓励开发人员考虑其更改的影响。 这对每个人来说都是一场胜利。

@jdalton ，集体诉讼。 :)