问题标签 [semantic-versioning]

在制作包时，我经常对是否应该使用any约束感到困惑。

我知道：

• library packages，我应该指定明确的版本约束，以便我的库的用户知道我的传递依赖项的版本，

• 应用程序包，我应该使用any并签入我的pubspec.lock锁定文件，以便其他人可以运行我的应用程序，

但有一个灰色区域：

• 旨在扩展的应用程序，例如代码实验室、教程、模板、示例等。

• 具有可重用库的应用程序；也就是说，具有lib通用功能目录的包，放在单独的包中没有意义，但也有web一个完整应用程序的目录。

问题：什么时候应该使用any版本约束，什么时候应该完全指定 Pub 包的版本约束？

我正在考虑采用semver作为另一个库的包装器，该库也遵循 semver。最初我以为我会保持包装器的版本与原始库相同，因为理想情况下它们会一直完全匹配。

然而，这并不是那么简单，因为包装器本身可能存在与原始库无关的错误和补丁，更不用说包装器开发本身是增量的，并非所有功能都在一夜之间准备就绪。

考虑到包装器引用的原始库的版本以及包装器本身的补丁和开发历史，推荐的对此包装器进行版本控制的方法是什么？

我真的很喜欢语义版本控制方案，但它真的只对 API 有意义，因为重点是突破性更改和向后兼容性。对于非 API，例如最终用户软件，许多规则不再有意义。例如，向后兼容的概念本身并没有任何意义。用户体验新功能或不体验，减少错误或不体验，等等。但是，我将从遵循语义版本控制精神的明确 xyz 版本控制方案中受益，以便用户可以了解会发生什么如果他们熟悉该方案，则从新版本号开始。

我试着画一些东西，比如：

• 如果对不改变用户体验的代码进行内部更改（例如错误修复、重构），则 Bump z。可能包括新的“内部”功能。
• 如果添加的功能会改变用户体验，而不是对当前功能的错误修复，请撞 y。
• Bump x...???...对用户体验有根本不同的改变？有什么根本不同？
• 初始 alpha 发展发生在 0.0.z
• 第一个 beta 测试版本设置为 0.1.0 并保持为 0.yz
• 第一个用户版本设置为 1.0.0

另一个想法是在删除功能时产生 x 颠簸，因为某些用户可能会依赖它们，但在某些情况下这似乎没有根据。（假设您认识所有的用户，他们都希望删除一个非常小的功能。从 1.0 升级到 2.0 有点违反直觉。）

这比语义版本控制更主观，因为客观地识别向后兼容的功能和 API 的破坏性功能要容易得多。是否有任何“标准化”版本控制方案可供我探索以获得更多指导？

We've recently started using our own internal NuGet server to house packages that are common to many of our internal projects. Originally, every project we work on is versioned with the build date in the format:

However, during our process to upgrade to .NET 4, we've decided to start versioning our packages with SemVer starting with v4.x. The problem is that NuGet treats the v4.x versions as OLDER than the ones versioned with the date format. In addition, projects referencing the v4.x versions think they need to upgrade to the versions with the date format, which aren't even targeting the same framework version.

Is there some way to configure NuGet such that package upgrades can't cross these versioning lines?

For inter-package dependencies, we have configured them with specific version dependencies such that dependencies themselves work OK. It's the main project reference that is the issue where "upgrades" may accidentally happen to an older version.

在编写 bower.json 时，您可以在依赖项中指定版本号。有时我看到人们在写

～到底是什么意思？为什么不写 >=0.3.13？

这是某种最佳实践吗？

Bower 使我能够使用以下语法指定软件包的版本要求：

但我一直无法找到用于<version>. 我知道我可以指定版本为：

• 大于某个版本">1.0.0"
• 大于或等于一个版本：">=1.0.0"
• 或在某个范围内："1.0.0 - 2.0.0".

我也知道有一个包含波浪号的通用版本语法："~1.0.0"。但我不确定它的含义以及它是否与"=1.0.0".

我也有兴趣知道我是否能够指定多个非连续版本，例如完全1.0.3加版本大于1.5.0等...

我们正在向我们的 Java 库引入语义版本控制 ( http://semver.org/ )。

我们应该如何处理添加新的枚举值？我们的情况如下：

• annotations.jar包含具有类型属性的注释MyEnum
• util.jar具有使用注释的对象注释的对象annotations.jar
• wsprovider.jar使用类似 jaxb 的技术将带注释的对象从util.jarweb api序列化
• wsconsumer.jar使用由 提供的 web api wsprovider.jar，并根据 的值进行切换MyEnum以更改其行为。

如果我们向 中添加一个新值MyEnum，我们应该碰撞各种 jar 的哪些部分（主要/次要/补丁）？

在我看来，util.jar需要升级主要版本，因为 API 的更改方式可能会破坏现有代码。

按照同样的逻辑，这将波及到 和 中的一个主要wsprovider.jar碰撞wsconsumer.jar。

是否annotations.jar需要一个主要版本的碰撞？

我会说是，因为枚举是一组封闭的值，所以代码（例如wsconsumer.jar）假设通过覆盖枚举中的所有值，它涵盖了所有可能的行为。向枚举添加一个新值然后打破它。

但是，本能地，将单个值添加到枚举中似乎有点多，并且具有相当大的连锁效应。

我想这只是我们需要习惯使用 semver 的东西吗？

假设您将 Git 中的一个分支合并到另一个分支（当然不是快进）。而且你没有冲突，所以合并应该是成功的，没有中断。但是由于某些原因，您希望直接对此合并文件树进行一些手动更改，以成为此合并提交的一部分。怎么做？

为什么我需要这么奇怪的东西？这是由于我的工作流程（实际上这可能也是一个需要改进的主题 - 所以这里的建议非常受欢迎）：我有一个“主”分支，当我想实现一个新功能时，我派生了一个新分支从 master 并使用它直到功能完成。然后我将此分支合并到主分支（使用 no-ff 模式）。但是这里的问题是我的版本策略（具体的语义版本）需要在完成新功能的同时增加版本号。因此，此时我必须直接向 master 提交另一次提交，对配置文件进行非代码更改，表明这是一个新版本。结果，我必须在 master 中提交两次提交，以引用新版本：合并提交，而新版本的配置中没有指示，然后提交带有此类指示但没有对代码库进行任何实质性更改的提交。因此，乍一看，合并此类提交会很好。但我不知道怎么做。

我将我的“angular-backstrech-adrr”版本注册到凉亭：

bower register angular-backstrech-adrr git@github.com:AladdinMhaimeed/angular-backstrech-adrr.git

这是 bower.json：

}

Bower 说它已成功注册，但是当我使用时：

它说没有可用的版本。

如果我更改版本并尝试再次注册，我会得到：EDUPLICATE

bower.json 有什么问题吗？语法有什么问题吗？

我正在使用 TeamCity 和 Github 自动化语义版本控制，并且我正在尝试找到一种计算直接影响 master 分支的提交的方法。

Git-Extensions 的这个带注释的屏幕截图可能最好地解释了这一点。我想自动计算箭头中的版本号：

作为构建过程的一部分，我正在使用 ruby​​ 和 octokit 来查询 GitHub API。当提交或合并符合主要/次要版本时，主要和次要版本号会手动增加，因此伪代码基本上是：

1. 找到major.minor.0对应的commit
2. 计算自 major.minor.0 以来更改主分支状态的每个提交
3. 将补丁版本设置为 commits.count

我遇到的问题是，如果我只计算对 master 的提交，每次接受拉取请求时，提交计数都会增加n+1，其中n是对分支的提交数。这会起作用，但它......不优雅。是的，我知道当您接受拉取请求时，您实际上是在接受该分支的整个历史作为您的“主”历史的一部分，但对于版本控制而言，这并不重要。

有谁知道我如何通过 GitHub API 过滤提交，以确定提交是否在创建时直接影响了master，或者是否有某种原因这实际上是不可能的？

谢谢！