【问题标题】:Why auto increment build version number?为什么要自动增加构建版本号?
【发布时间】:2015-12-13 22:54:22
【问题描述】:

您好,这不是关于版本的问题,而是关于以下问题的一般性讨论:为什么要自动增加构建版本号?它有什么实际用途吗?

说,我在 1 个月前输入代码,假设版本号是 1.0.0.0

今天我重建它,旧代码相同,但版本 # 是 1.0.123.0

对我来说,与 1 个月前相比,它是相同的旧程序集,但为什么版本不同?

imo,只有在代码更改或任何会影响代码行为的更改时才应自动更改版本号。

ps:要去设置TFS,在琢磨这个

【问题讨论】:

  • 嗯,something(或somebody)正在设置内部版本号,程序集清单文件是什么样的?我个人认为应该始终明确指定前导三元组..
  • 您的AssemblyVersion 属性内容是什么样的? (另见this question/answer。)
  • 嗨,这不是版本问题,而是一般性讨论
  • 我会区分:保持相同的 AssemblyFileVersion (因为从技术上讲它是相同的源(并且希望是相同的工具 - 无论如何这里可能有理由增加)),但请注意实际上是通过将当前日期/时间戳之类的内容放入 AssemblyInformationalVersion 进行重建。
  • 无论出于何种原因,该线程被否决了,不妨将其删除,因为我不再需要为 tfs 操心

标签: .net tfs


【解决方案1】:

这完全取决于您增加版本号的标准。大多数人坚持 increment at each build 规则,因为这是最容易实现的,但您可以使用不同的规则。 选择一个版本控制标识符(如变更集编号或 Commit Sha)会很好,但实际上不可能使用它们,除非在像 AssemblyFileInformationalVersion 这样的描述性位置。

也就是说,仅在代码更改时增加版本号是可行的,但这需要一定的努力,并且很快就会变得困难。例如

  • 你怎么知道代码变了?
  • 构建成功后,版本号存储在哪里?
  • 您在组装级别或每个产品/包装上跟踪编号?
  • 不同的分支有相同的版本号吗?

我在一系列帖子(firstsecondthird)中描述了一种 MSBuild/TFS 技术。你可以看到它的主要缺点:版本号在构建服务器上;机子丢了,只能手动恢复号码系列。

您可以在GitVersion 找到其他有趣的想法。在这里,该工具根据提交历史计算版本号。

【讨论】:

  • 你怎么知道代码变了? -> 我们可以依赖源代码控制,每当提交 chk in 时,只需假设涉及更改。良好的源代码控制应该能够检测到 chk 与存储库有差异,如果没有更改,则应该忽略提交,因此没有版本增量
  • 帖子中有详细描述:您只获得更改的文件,并利用 MSBuild 智能仅重建需要的文件。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-10-10
  • 1970-01-01
  • 2021-03-01
  • 1970-01-01
  • 1970-01-01
  • 2016-06-03
相关资源
最近更新 更多