1

八年后，我遇到了与nuget 提要和促销相同的问题！

在这种情况下，我说的更笼统；我们使用 ProGet 作为我们的包管理器，并且在包推广过程中需要考虑 nugets、通用包，甚至一些 docker 容器。

其中一个想法是拥有多个 Nuget 提要；一个 ci 提要，每个成功的集成都会发布一个包，一个 qa 提要，您只发布您希望 qa 测试的版本，然后是一个发布提要，您只从他们成功测试的 qa 提要中复制包。

所以，假设我们在ci提要中有一个可以工作的版本，它是 version 1.2.3-ci-xyz。我们希望将其推广到 QA 提要，无需重新构建，并将其重新打包为1.2.3-rc-1. 该软件包通过了 QA 并准备好升级到 prod 提要中，无需重新构建并交付生产。它应该作为1.2.3. （正确的？）

问题是，如果我们不进行任何重建，软件包二进制文件仍将具有 version 1.2.3-ci-xyz。这将显示在应用程序中显示或查询版本的任何地方。

这就是我卡住的地方。这里的正确模式是什么？只要我们知道它是什么，发布什么版本是否重要？

  • 意思是，我们从较低的提要推广1.2.3-ci-xyz到较高的提要，而无需重新包装不同的版本？
  • 包1.2.3中包含二进制文件不是不正确1.2.3-ci-xyz吗？
  • 我们是否总是使用下一个 3 位数字构建，而忘记 ci/rc 后缀？
4

1 回答 1

0

我将从我们的内部支持渠道分享这个答案:)

这就是我们（Inedo）通常在我们的库中处理这个问题的方式。简短的回答是：

  • 我们将程序集版本设置为 Major.Minor.Patch
  • 我们将程序集文件版本设置为 Major.Minor.Patch.Build
  • 我们将包版本设置为 Major.Minor.Patch-ci.Build（然后我们重新打包为 Major.Minor.Patch-rc.Build，然后重新打包为 Major.Minor.Patch）
  • 我们还使用 Assemble Informational Version 来显示友好的版本（例如：版本 6.0.0 (Build 36-v6)）

这允许我们在不重新构建的情况下重新打包。我们还将在产品构建期间检测这些预发布依赖项，并防止它们被发布到生产环境中。您可以查看我们的 ProGet v6 版本作为示例：ProGet 6.0.0 Build 36。

我觉得较长的答案在我们的博文 Best Practices for Versioning NuGet Packages in the Enterprise 中得到了很好的回答。

于 2021-10-15T01:11:30.450 回答