问题标签 [semantic-versioning]

有时版本信息必须嵌入到输出工件的元数据中。因此，版本必须在构建/编译时确定。

但是，在您实际发布语义版本控制之前，您不能调用版本，因为最后一位数字必须是增量的。

例如

发布过程有 6 个步骤。提交 1 和提交 2 触发了 2 个构建。

在提交 1 完成步骤 6 中的发布过程之前，您无法真正确定语义提交 2/构建 2 将是什么。如果提交 1/构建 1 失败，则提交 2/构建 2 将为 1.0.0。如果构建 1 成功，构建 2 将是 1.0.1。

如果您正在创作 nuget 包或 .net 二进制文件，则版本信息将已经在工件本身中，并且无法更改。

如果这个问题被张贴到错误的空间，我深表歉意——对于 SO 来说感觉不太合适，但我不知道有更好的地方。

我有一个公共 nuget 包（EnumStringValues ... plug、plug plug），我正在对其进行更改。

更改不会更改 API 签名 - 旧代码仍将编译。但它确实会改变边缘情况下的行为 - 主要结果是以前会生成异常的用法现在执行不同的默认行为。还有一个 TryParse() 调用，它将（在这种边缘情况下）将（非异常）失败案例更改为成功案例。

极端情况是“您以一种并非真正打算使用的方式使用了这个库”。即我略微增加了库的预期使用范围。

这是一个突破性的变化吗？因此它需要一个新的主要版本吗？或者它仅仅是一个“向后兼容”的小改动。

我的第一直觉是说这是对现有调用行为的改变，因此是一个重大改变。想法？

这个问题适用于任何用一种语言（“源代码”）编写的语言，例如 C 或 Java，并使用动态链接以另一种语言（“二进制”）分发，例如机器代码或 Java 字节代码。

假设用户已经在使用我的库的 A 版。我发布了一个更新的版本 B。

如果他可以编译他的代码而无需对 B 进行更改并正确地与 B 一起运行，则从 A 到 B 的更改被称为source compatible。

如果他可以针对 A 编译他的代码并正确地与 B 一起运行，则从 A 到 B 的更改被称为是二进制兼容的。这种情况在使用没有隔离模块加载的传递依赖图（例如 OSGI）时很常见。X 是针对特定版本的 Y 和 Z 编译的，而 Y 是针对不同的特定版本 Z 编译的。在运行时，Y 对 Z 的调用可能不正确并且可能会崩溃。

更改可能是源兼容的，但二进制不兼容。更改也可能是源不兼容和二进制兼容的。

我将哪种兼容性用于语义版本控制？我是使用源兼容性来区分主要和次要/补丁更新，还是使用二进制兼容性来区分主要和次要/补丁更新？

我目前的动机是 Scala 库。Scala 二进制兼容性可能很难分析，需要对编译器细节有很好的理解。源代码兼容和二进制不兼容是很常见的。

这不是一些奇怪的边缘情况。这个问题可以出现在大多数任何编译的、动态链接的语言中。

假设您正在使用Devise宝石。您应该在 Gemfile 中使用以下哪个版本：

'devise', '~> 3.5.1'

或者

'devise', '~> 3.5'

使用其中一种的优点和缺点是什么？

根据 RubyGems：

PATCH 0.0.x 级别更改，用于实现级别的细节更改，例如小错误修复

任何向后兼容的 API 更改的轻微 0.x.0 级别更改，例如新功能/特性

针对向后不兼容的 API 更改的主要 x.0.0 级别更改，例如在更新时会破坏现有用户代码的更改

那么使用它们是否有意义，'devise', '~> 3.5'因为一旦bundle update运行它们就会得到小错误修复？

我正在计划将我们的 build.gradle 文件转换为使用语义版本。除了使用 Gradle 之外，我们还使用 Git 并遵循 Gitflow 工作流程。Jenkins 用于构建项目。

已发布工件的版本遵循 MAJOR.MINOR.PATCH 格式。在 build.gradle 文件中声明依赖时，我们使用动态版本，例如 10.0.+（即取最新的 10.0.PATCH 版本）。

我们将我们的工件从候选发布存储库提升到 Nexus 中的发布存储库。存储库的策略设置为“发布”。由于产品的复杂性（200 多个项目，具有许多上游和下游依赖项），Jenkins 可用的许多推广插件似乎都达不到要求。我们正在考虑让 Jenkins 构建主分支作为重命名工件（10.0.0-rc.1-abcdefg 变为 10.0.0）并将它们上传到正确的 Nexus 存储库的一种方式。

我不确定如何处理上游依赖项的补丁版本增加的情况。下游项目 - 一个 WAR - 由 Jenkins 重新构建并捆绑新的 JAR，但下游项目的版本不会改变。当尝试上传到 Nexus 时，它会失败，因为只有一个工件可以具有相同的版本。

这是一个例子：

• Releases Nexus 存储库的上游 API 版本为 10.0.0，下游项目版本为 10.0.0
• 下游项目依赖于 10.0.+ 的上游 API
• upstream-api.jar 被捆绑到了下游项目.war 文件中
• 这两个工件被部署为产品版本 X 的一部分
• 当一个 hotfix 分支合并到 master 时，upstream-api 版本已更改为 10.0.1
• 该修复意味着在部署时，产品现在是 Release X'
• 下游项目保持在10.0.0，但是由于上游依赖的变化而重新构建
• Jenkins 无法将下游项目 10.0.0.war 上传到 Nexus，因为它已经存在

我可以用新的工件替换旧的工件，但这意味着不能再从 Nexus 中的工件部署 Release X（例如，在回滚的情况下，或者需要在旧版本上复制问题）。

这通常是如何处理的？

我需要一种在 posix 环境中操作 semver 值的相当便携的方法。

具体来说：
1. 排序，以及
2. 递增以下之一：major、minor、patch 给定的 semver 值。

这是一个非常简单的例子来说明这个问题。

我正在尝试react-native@0.8-rc与react-native-linear-gradient.

react-native-linear-gradient定义react-native@>=0.4.4为对等依赖项。很公平。

我跑npm install。

我收到一条错误消息

react-native@0.8-rc不满足react-native@>=0.4.4。

这个问题npm毫无用处，因为它妨碍了开发人员和包维护人员。有关示例，请参见此处。

任何使用节点的人如何对候选版本做任何有用的工作？！？！解决方法是什么？

供您参考，来自 NPM 3.1.2（撰写本文时的最新版本）的错误如下所示：

我有一个很少发布的 GitHub 项目：

• 1.0
• 1.5
• 2.0
• 2.1

我被要求修复 1.5 版中的错误。最好的做法是什么？

我应该检查1.5，修复错误并将其推送为1.5.1吗？

这是正确的方法吗？

使用语义版本控制，如果我的 API 的功能之一发生以下更改：

这是否需要新的主要版本，还是可以在次要版本下通过？

似乎版本控制的工作方式与以前版本的 .Net 不同。project.json 似乎使用了语义版本控制（从我在网上看到的），格式为 Major.Minor.Patch-Special。

1. 这会取代组装版本的想法还是增加它？或者它只是与 Nuget 一起使用。
2. 在运行时如何访问版本。我在 Microsoft.Framework.Runtime 包中在线遇到了 Nuget.SemanticVersion 对象，但我不知道如何在代码中检索它。
3. 是否有编程方式来更新构建或自定义脚本上的这个值？