问题标签 [semantic-versioning]

我正在构建自己的 rpm。现在我有构建版本0.1等0.2。我想使用语义版本控制。现在我想知道当我改变它时依赖关系将如何工作？

假设我有旧版本0.5和新版本0.6.0；这些数字将如何解释？

旧版本会被解释为0.5.0还是0.0.5？如果我有另一个取决于版本的 rpm，0.4.0我可能会遇到麻烦……那么0.4.0与 相比如何0.5？

所以“myLibrary”引用“anotherLibrary”。这两个库都遵循http://semver.org/

如果我发布了 myLibrary 的新版本，强制消费者更新到 anotherLibrary 的新主要版本，myLibrary 的主要版本是否也应该增加？

我开始开发一个我想开源并在未来项目中使用的包。我不明白开始这个的正确步骤。

我刚刚在 github 上创建了存储库，这是我的composer.json

不过，我很难解决版本控制问题。我还没有制作任何 git 标签。我穿上它branch-alias只是因为我听说这是一个很好的做法。我不确定1.0.x-dev现在应该有什么。

此时我该怎么办？我对 1.0 版本还不是很满意。我应该立即在“v0.1.0”之类的地方创建一个轻量级或带注释的 git 标记，还是等到它完全发挥作用？

我应该怎么做，这样以后就不会头疼了？

我假设作曲家使用 git 标签进行版本控制（？）

我有一个maven multi-module项目，其中包含超过 6 个子模块。如果一个 3 人团队并行工作，sub-modules每个任务 2 人，那么如何增加版本号。

而我Major.minor.patch-meta在发布周期中遵循版本编号格式。

增加和减少版本号的确切用法parallel programming，而要通知的关键是sub-modules该项目中的一些完全取决于其他一些sub-module，如果是这种情况，那么如何在开发并行时准确地进行版本号以及某些命令 ？

我不清楚以下内容，但这是正确的版本编号方式

1. meta release如果修复错误，例如 alpha、beta、gamma 等，我是否需要做这些，

2. 如果我正在使用例如 0.1.1-alpha、0.1.2-alpha 等，我是否需要在完成 a的patch release情况下执行 afeature[sub-sub-module-x]sub-modulesecond level+ sub-modules

3. minor release在完成例如 0.2.0-alpha 、 0.2.0-RC 等的情况下，我是否需要做一个sub-module。
4. 因此，在整合了所有 RC 的 0.2.0-RC + 0.3.0-RC + 0.4.0-RC 等之后，我是否需要做major release1.0.0-RTM 等，

所以理解上述流程有点令人困惑..

有什么方法可以自动化build numbering项目中的内容以保持清晰build release numbers。请提供解决方案。

谢谢

我们有一个内部 Java 库，它是许多其他项目的依赖项，我们称之为our-commons-<version>.jar. 我们或多或少喜欢遵循语义版本控制的想法，所以：

• 当我们进行向后不兼容的 API 更改时，主要编号会发生变化；
• 当我们进行向后兼容的 API 更改时，会发生较小的数字更改；
• 每次我们进行构建时，补丁号都会更改（所以对我们来说，它实际上是一个构建号）；但我们真的只会在修复错误时构建，所以它足够接近真实semver

目前，我们只发布到 Artifactory 上的 SNAPSHOT 目录，并覆盖每次构建时存在的 JAR。具体来说，我们的项目仓库位于：

机器http://arty/artifactory上运行的 Artifactory 服务在哪里，实际 repo的名称在哪里，我们的 lib 的名称在哪里。目录是所有 Bamboo 构建发布到的地方，就像我说的那样，覆盖每个构建的 JAR 。我们正在硬编码我们的构建以生成每个构建。artyour-libs-snapshotsour-commons/snapshotour-commons-0.1-SNAPSHOT.jar

要进行此发布，我将以下任务配置为 Bamboo 计划的一部分our-commons：

我试图弄清楚如何让 Bamboo 和 Artifactory 与我们的 semver 风格一起工作。这样我们第一次构建时，它将产生：

我们第二次构建时，它将产生：

等等。然后，我们将能够手动指示何时要增加次要编号，在这种情况下，补丁编号将重新开始：

主要编号的处理相同，但递增会重置次要编号和补丁编号。

不确定我们应该在哪里添加这些配置，或者它们实际上会是什么样子。有任何想法吗？

I have the following:

which works when versions are like this:

but it will not match

as it will return only

but I want the versionShort to be set to

I am wanting to match the major version, the first dot and the minor version as above.

假设您正在开发一个平台，该平台为其用户提供基于 Web 的界面，并为第三方开发人员提供 API。类似于 Salesforce（甚至 Facebook）的东西。

Salesforce 和 Facebook，这两个平台都为其用户提供基于 Web 的正常界面，并为第三方开发人员提供 API。

理想情况下，任何 API 在内部调用基于 Web 的界面所使用的相同函数。例如，“创建项目”按钮和“CreateProject”API 在内部调用相同的“createProject()”函数。因此，您可以为两者保持相同的版本，因为在大多数情况下它们是紧密集成的。

现在有时您添加一个功能，使您增加基于 Web 的界面的次要版本，但由于您没有在 API 中实现该功能，因此 API 版本应该保持原样。

您如何处理此类案件？您是否应该为您的平台维护基于 Web 的界面和 API 的单独版本？

我找到了这篇博文和相关的Gist。作者似乎没有创建相应的 NuGet 包。

有人知道已经存在的 NuGet 包吗？

作为参考，这里是语义版本控制的规范。

使用semver 包我没有看到一种简单的方法来检查我是否需要一个库版本是否有兼容的版本。这让我想知道我是否遗漏了一些明显的东西，因为它看起来像是一个常见的操作。

根据Semver.org，任何相同或新但不在新主要版本中的版本都应该是兼容的。因此，如果我需要1.2.3并且我有，>=1.2.3 <2.0.0那么一切都很好。我可以手动进行比较，这似乎很常见，以至于我很好奇我是否错过了一种更简单的方法。

换句话说，看来我显然必须这样做

哪个有效

是的，这是一小段代码。看起来这将是一个如此常见的操作，我不必操作字符串并手动构建范围比较只是为了检查一个常见的问题，X 是否与 Y 兼容。

有没有更简单的方法？

长话短说，我是 VisualBasic 6 项目的维护者，该项目生产的 ActiveX COM DLL 被组织内部使用的约 50 个其他软件包在内部使用。

在过去的几年里，我们一直在为每个发布的 DLL 遵循语义版本控制“MAJOR.MINOR.PATCH”，并为每个发布分配一个唯一的 GUID。即 1.1.1 和 1.1.2 有单独的 GUID。

它工作正常，但这会导致每个软件包都需要一个新版本——即使不需要任何软件包——只是为了它们可以引用新的 GUID 并重新编译。由于发布的内部流程，这浪费了几十个工时。

我的问题是，为每个 MINOR 版本维护一个 GUID 以使 1.1.1、1.1.2 甚至 1.1.99 都具有相同的 GUID 是否是一种“不好的做法”？每个主要版本都做一个 GUID 会更好吗？

这将导致仅在制作新的主要或次要版本时才更改引用，从而减少依赖于它的软件包所需的更改数量。

最后，如果它有助于响应，当前 DLL 被命名为：MyActiveXDLL_vMAJOR.MINOR.PATCH.dll。

使用每个 MINOR 的 GUID，我们将切换到 MyActiveXDLL_vMAJOR.MINOR.dll