Flo*_*tto 7 c# versioning git nuget jenkins
我们刚刚开始研究可能最好被描述为公司范围的“开放”源代码框架的东西。我们的主要语言是 C#，我们使用 Jenkins 和 ProGet 来创建和共享 nuget 包。我们开始把所有东西（我的意思是所有东西。一个模块至少有三个存储库）放在它自己的 Git-repo 中。我们认为这是一个好主意，因为我们可以单独版本和发布所有内容，但如果您想对具有依赖项的多个存储库进行更改，结果会导致非常烦人的工作流程。
我开始环顾四周，似乎大多数项目都使用更加单一的方法，我认为这也可能会让我们在这里的生活更轻松。我不太确定的是，这种方法的版本控制是如何工作的。
CoreFx 存储库是我们正在努力实现的一个很好的例子。一个 repo 导致许多单独的包。当我在本地构建它时，所有包都有一个版本号，但是当我查看 nuget.org 上的可用包版本时，版本似乎是每个包的。例如 System.Diagnostics.DiagnosticsSource 版本为 4.5.1，但引用 System.Diagnostics.Debug 版本 4.3.0。
所以这正是我认为对我们来说是一个很好的解决方案。一个 repo，许多具有独立版本的结果包。
有谁知道这是如何通过 corefx 项目实现的，或者有任何其他建议，怎么做？
monorepos 和very-many-repos 都有优点；许多小型存储库的优点之一是您可以轻松地获取git tag单个软件包的特定版本。有时在单一仓库中做同样的事情会更尴尬。
但是，如果您要发布的更多的是“一组相关的包”，那么这也许并不是一个坏主意：您可以使用一个.bat或.ps1文件来为您的存储库构建所有 NuGet 包并相应地设置版本号。就像这个例子（Powershell脚本）
您正在谈论的引用/依赖项（System.Diagnostics.DiagnosticsSource版本 4.5.1 取决于版本 4.3.0）成为“消费”包中的各个标签System.Diagnostics.Debug（即在本例中）。在这里，您可以选择两种主要策略：<dependency>.nuspecSystem.Diagnostics.DiagnosticsSource
<dependency>版本，以便“升级一个即可升级所有”软件包。有时这就是你想要的，然后你就应该这样做。后一种策略可以说是更优雅的方法，但也更复杂（可能需要更多的工作才能以良好的方式完成）
假设我有项目 A 和项目 B，它们引用了 A，并且两者位于同一个存储库中。我还有一个针对项目 B 的 Visual Studio 解决方案，其中包含对项目 A 的项目引用。
现在，我对项目 B 进行了更改并增加了它的版本，而不增加项目 A 的版本。我推送了我的更改，Jenkins 对存储库进行了彻底的签出并构建了创建两个包的解决方案，但包 A 现在具有相同的版本就像之前的版本一样，无法推送到 nuget feed
这确实是一个有趣的问题。一些潜在的解决方法：
让 Jenkins 检测/确定更改之间的增量，并仅为树中已更改的部分构建包。可能可行，但也许不是很容易；需要脚本中有一些逻辑.ps1。也许是我能想到的最优雅的解决方案。
使因“版本已存在”而失败的 NuGet 推送成为非致命错误。即检测运行时nuget push是否出现特定错误（非常重要的细节！）并忽略它。您绝对不想忽略其中的所有错误nuget push，而只想忽略这些特定的错误。不太优雅，但仍然是全自动的。
使发布包成为半自动而不是全自动的过程。在 Jenkins 中设置一个或多个作业，当要发布包的新版本时，您可以手动“按下按钮”，也许有一个作业参数说“要发布哪个包”（可以是 Jenkins 中的下拉菜单，因此没有人知道）手动输入名称。）听起来本质上可能有点手动，但此选项可以让您作为一个团队对推送哪些包以及何时推送进行最大程度的控制。
（关于一般的 monorepos，不是专门处理你提到的 CoreFx 案例。不过仍然可以提供有价值的信息。）