Nuget 包版本控制/更新策略答案

【问题标题】：Nuget packages versioning/update strategyNuget 包版本控制/更新策略
【发布时间】：2019-04-07 07:44:07
【问题描述】：

也许有人对以下场景有一个好主意：

我有预发布开发包，例如：packagename.1.2.0.1000-dev.nupkg 和发布包，例如 packagename.1.2.0.1.nupkg

我的想法是：如果开发人员在 nuget 更新步骤中启用了 Pre-Release 选项，那么从更高的开发包数量范围开始将始终允许为开发人员获取开发包。这工作正常。然后稍后我想将项目更新到最新版本。但是似乎没有选项可以更新到版本号低于 dev/pre-release 包的最新版本？此外 -Safe 选项似乎在这里不起作用。

我也无法使内部版本号保持同步，因为它们是不同的版本。如果我有相反的方式，那么发布版本的内部版本号更高，如果我进行正常的 nuget 更新，它永远不会更新到最新的开发包，即使包括预发布包......

这里有什么想法吗？

非常感谢！

【问题讨论】：

我建议使用semver，而不是旧的四位数方案。无论哪种方式，您都必须正确使用您选择的任何方案。你不这样做。见docs.microsoft.com/en-us/nuget/reference/package-versioning。
嗨。好的，我知道 semver 只使用 3 位数字或新的 semver 2.0 允许点表示法。但据我所见，这无法解决如何更新到仅发布包，即使（因为它是自动构建），预发布包的最后构建/版本号可能高于已发布版本的版本号
是否允许预发布包始终取决于客户。

标签： nuget nuget-package semantic-versioning nuget-update

【解决方案1】：

任何公开可用的包在技术/英文术语中都是“发布包”。但是软件行业已经将这种语言混为一谈了。那么让我们来谈谈稳定（无预发布标签）和不稳定版本（预发布标签）。

发布者历史应该是这样的：

1.0.0 // First **stable release**
1.0.1-alpha // First **unstable release** Candidate bug fix.
1.0.1-beta  // 1.0.1-alpha with a tweak to the code.
1.0.1 // Second **stable release**

如果发布者遵循该模式，则最终用户客户可以安全地提取稳定版本错误修复，而开发人员也可以自行决定提取不稳定的预发布版本。

你也可以有类似的东西：

1.0.0 // First **stable release**
1.0.1-a.dev.1 // Next CI build after 1.0.0
1.0.1-a.dev.2 // Etc...
1.0.1-alpha // Relabeled 1.0.1-a.dev.2.
1.0.1-beta  // Relabeled 1.0.1-alpha, wider audience than -alpha.
1.0.1 // Second **stable release**

最好为内部开发/测试、公开预发布和公开稳定版本提供单独的提要。

【讨论】：