Backbone: 关注 SemVer

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

如果我们严格遵循“语义”版本控制，那么现在可能是Backbone.js 43.0.0——这无助于任何人评估项目的实际进度。

所以，正如我喜欢开玩笑的那样——不是“语义”版本控制，_浪漫版本控制_。

给定版本号 MAJOR.MINOR.PATCH，增加：

当您发布主要新版本或显着更新和/或稳定 API 时的主要版本。
添加次要新功能时的 MINOR 版本。
PATCH 版本，当您进行微小更改时，可能会被大多数人忽视。

这允许人们在听到新版本时立即对其范围有一个粗略的认识。 至于向后兼容性 - 理想情况下 _every_ 版本，即使是主要版本，也是向后兼容的。 当它们不能时，因为 API 正在发生变化，它应该以一种不太难升级的方式来完成。

但是避免对 API 进行任何更改，并等待“主要”版本准备就绪将是进展的巨大障碍。 频繁增加 MAJOR 版本号的替代方法非常无用。

老实说，我更喜欢只使用BIG.SMALL版本号的更简单的方案——就像大多数桌面应用程序一样......但我担心它会破坏包管理器和其他工具。

使用 Backbone 43.0.0 有什么问题？

• 从 Chrome 32.0.1700 发送

+1 为 spadgos@ 问题。 版本号是任意的。 出于某种原因，我们有敏捷的 Web 应用程序试图保持在与操作系统相同的范围内。 许多应用程序都对超过 10 年感到害怕……但是您建模的大多数项目（Windows、Linux 等）在发布前都有 1 年/多年的开发周期，因此 1.x -> 2.x是件大事。 敏捷项目进展非常迅速，快速增长也很有意义。

我也不同意这背后的推理。

Marionette 现在在 v1.2.3 上，并且最好遵循严格的语义版本控制。 到目前为止，即使我们也是“所有表面积”，我们也没有遇到任何问题。 我们添加了新功能。 我们已经修复了错误。 但是 v1.0 仍然兼容 v1.2.3。 当 v2 版本是 API 或预期的行为破坏性更改时，我们已推迟它们的票证。

在接受拉取请求时，不必每周都发布具有重大更改的主要版本。 这些可以（并且应该）合并到主要版本中，这些版本为具有主要版本碰撞的大型版本提供足够的价值。

就目前而言，在 v1.1 版本中破坏兼容性会给插件和附加组件开发人员带来很多痛苦，例如 MarionetteJS 团队。 我们不得不在我们的代码中用补丁来回填行为，这样我们才能在 v1.0 和 v1.1 中保持可行……这不是一个有趣的情况。 像 Backbone 这样的核心库发生重大变化的连锁反应是巨大的……不仅仅是 Backbone 受到影响。

我同意这似乎更像是“不想”而不是“不能”的情况。 诸如https://github.com/jashkenas/backbone/pull/2461 之类的重大更改没有真正的紧迫感，如果您不想要 43.0.1 问题，可以等待主要版本更新。

对我来说，Backbone 不尊重 semver（除其他外）的最大问题在于教导和传播 Backbone。 告诉一群学生或潜在客户你的堆栈中的所有东西都将以某种方式工作，这并不是一件好事……除了 Backbone。

在“宣传”Backbone 时总是有两个巨大的警告：它不是开箱即用的 AMD，它不尊重 SemVer，所以不要认真对待版本号。 其中之一是固定的。 让我们修复另一个。

老实说，我更喜欢只使用 BIG.SMALL 版本号的更简单的方案——就像大多数桌面应用程序一样......但我担心它会破坏包管理器和其他工具。

@jashkenas我们总是可以将第 3 位数字保留为 .0 :)

这可能在语义上映射到 SemVer 比我们现在正在做的更接近一点。 也许这会抑制一些被动攻击性的加密政治狙击手，即不关注 SemVer 在技术上是如何错误的。

我认为 Bob 的观点是正确的，因为无论我们遵循什么系统，明确阐明我们遵循的系统更为重要。

ps 我并不是要暗示@keithamus的问题是被动攻击性的，如果它以这种方式出现，我很抱歉。 讨论 Backbone 如何向用户传达更改绝对是合法的。

：+1：用于服务器。 我主要对给定软件的版本感兴趣，而不是作为其进度的索引，而是其兼容性。

通常，在 1.0 之后（当时我希望事情基本稳定并且可以工作），版本号作为进度指标基本上没有意义。 与版本 2 的软件 Y 相比，版本 10 的软件 X 可能不那么成熟，功能也更少。如果您想了解某个软件的进度，则必须查看其变更日志或路线图。

知道 Backbone（或其他任何东西）在 2.4.3 就其功能而言毫无意义。 然而，它_应该_意味着我可以从我的 2.0.4 升级而不会出现任何中断。

如果我们严格遵循“语义”版本控制，那么现在可能是 Backbone.js 43.0.0——这无助于任何人评估项目的实际进度。

一个非常小的/可能不存在的问题。 不关注服务器？ 大问题。

:+1:, semver 对于这么大的项目来说是必备的。

我和@knowtheory 在一起。 43.0.0看起来有点奇怪，但我认为1.43.0会很好，没有人会在npm install之后意外损坏。

谁在乎版本号高？
这是一个标准，如果你可以使用它，你应该使用它。
我什至不明白为什么这个讨论会持续这么久。

:+1: 它可以避免 #2996 和 #2997 中的一些问题，以及其他几个 Backbone 版本的问题。

@braddunbar （以及“反对”的其他原因）听起来像是将版本号的美感置于其实际含义之上。

谢谢，但严格遵循“语义”版本控制对 Backbone 来说效果不佳。

我认为这更多是关于 Backbone 为其用户工作得很好（具有依赖性管理）。 以下哪个 semver 将保证......

更频繁的发布将有助于更快地捕获 showstopper 错误。 我认为要求人们不断运行边缘版本的 Backbone 只是为了获得他们需要的错误修复，这太过分了。

+1 @德里克贝利

就像这些自 1.1.0 以来的示例一样，补丁版本背后的想法是根本不需要这些修复程序。

https://github.com/marionettejs/backbone.marionette/commit/5a498d250d23a68c9c84a1362782edcf8774a1c8

https://github.com/marionettejs/backbone.marionette/commit/baed36bad8357e4379d4d2bc0460fd1375d2c85b

https://github.com/marionettejs/backbone.marionette/commit/e13e912bdda8e056c0e7b5e15d127eff158a48cb#diff -3c2771f47bdfe073ea95bfa54a37a972R167

对于 npm 或 bower 中的包，这甚至没有争议。

当您使用 npm 或 bower 发布包时，semver 是您签订的 API 合同的一部分。 当您违反该合同时，您就破坏了其他依赖于您的模块。 您破坏了依赖于您的模块的生产代码。

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

如果答案是否定的，那么应该大声而清楚地宣传，因为像安装遵循 API 合同的任何其他软件包一样安装您的软件包是不安全的。

当您使用 npm 或 bower 发布包时，semver 是您签订的 API 合同的一部分。

不，这不对。 npm install --save [email protected]不是一个繁重的要求。

@akre54我对你对 semver 的看法很感兴趣，我知道@jashkenas 对此有什么想法，但你的想法是什么。

@akre54是的，是的。 npm 假设存储库中的所有包都遵循 semver 。 这就是它如何确定哪些包与哪些包兼容。

从package.json文档：

“版本必须可以被 node-semver 解析，它与 npm 作为依赖项捆绑在一起。（npm install semver 自己使用。）”

如果您的版本号 _lie_ 在被解释为 semver 时，那不是正确的解析。 因此，您违反了package.json合同，并且违反了人们在 npm 生态系统中使用包版本的方式的兼容性。

这不仅仅是个人喜好的问题。 这是包互操作性的问题。

如果不使用 semver，是否可以强制您的软件包运行良好？ _当然_，是的，但是如果您不在自述文件的顶部大声而大胆地指出它--很少有用户会知道这是必要的，并且当您引入破坏性更改时，他们的代码很容易被破坏。

一旦您将包发布到包存储库，版本控制就成为互操作性合同的一部分。 您忽略该合同会使您的用户处于危险之中。

npm install --save [email protected]不是一个繁重的要求。

知道进入一个完整的应用程序的数千个包中的哪一个，你必须用_is_来做这件事，这是一项繁重的要求。 迫使用户严格锁定所有软件包的版本，因为少数模块不遵守规则_是一个繁重的要求，因为它使跟上错误修复、安全补丁等的问题变得复杂......

有很好的理由关注 semver。 “我的包裹号可能会变得非常大”是_不_使用 semver 的可怕原因。 跟踪应用程序的进度是软件包版本的第二个原因。 该版本最重要的功能是知道“这个版本是否适用于我的应用程序？”

顺便说一句，如果您的包裹号变得非常大，那可能是代码异味。 当您进行_重大更改_时，您只需升级主要版本。 定义上的突破性变化是_打破开放/封闭原则_。 对扩展开放，对重大变更关闭。 所有好的 API 都尽可能地遵循开放/封闭原则，以便用户可以跟上 API 的步伐，并且更改不会破坏现有代码。

我认为这里学到的教训是“通过 package.json 引入 Backbone 时不要使用~或^ ”

@akre54我对你对 semver 的看法感兴趣

总的来说，我同意这里的论点，但我确实想知道，在 _every_ 破坏性更改（再次强调，下划线主要是表面积，那是_很多_）时，撞主要版本是否是最佳做法。 Underscore 用于大量第三方库，要求它们都跟上大版本将是繁重和危险的。 （今天发布的包是否应该依赖 Underscore 直到版本 2？1.7？1.6.x？它是否应该以可能需要与主项目分开的 Underscore 为代价来固定其依赖项？）

我认为这里学到的教训是“在通过 package.json 拉入 Backbone 时不要使用 ~ 或 ^”

是的。

我认为这里学到的教训是“在通过 package.json 拉入 Backbone 时不要使用 ~ 或 ^”

我在上面概述了为什么这不应该是外卖课程。

我认为这里学到的教训是“在通过 package.json 拉入 Backbone 时不要使用 ~ 或 ^”

因此，这就是您所做的，以保护您的代码不被破坏。

教训更像是“遵循 semver 对每个人都有好处，不这样做则不然。”

我可以欣赏“浪漫”版本控制的价值。 太糟糕了，它们不能很好地共存。

需要注意的是，总会有一些项目没有非常严格地遵循semver，而那些试图但达不到要求的项目，所以系统总是有点泄漏。

至少 Backbone 通常非常擅长不破坏事物。

@dgbeck每个版本的事情都会中断，请参阅我之前的评论

所以我认为关注 semver 的价值还没有真正被讨论过，因为你们可以推送次要功能和错误修复，并允许上游依赖它的人免费获得这些更改。

对我来说，这是一个很大的增值，但显然这是以维护者的复杂性为代价的。