C#管理修订号的有效方法答案

【问题标题】：C# Effective way to manage revision numberC#管理修订号的有效方法
【发布时间】：2009-05-28 07:55:16
【问题描述】：

C# 2008 SP1

我想知道处理修订号的最佳方法是什么。

我一直以为通常只有 3 个数字。（主要、次要和错误修复）。

但是，我想知道内部版本号和修订号是什么。

例如，过去我通常只使用 3 个数字。我有一些非常小的更改或错误修复，我会增加第三个数字（错误修复）。

因为我是新手。专业领域通常会做什么？

非常感谢您的建议，

在我的 AssemblyInfo 文件中，我有以下内容：

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.2.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]

// 1.0.2 Added feature for detecting if a sound card is installed.

【问题讨论】：

标签： c#

【解决方案1】：

来自MSDN：

Build ：内部版本号的差异表示重新编译相同的来源。这将是因为处理器合适，平台或编译器更改。

修订：具有相同名称、主要和次要版本号的程序集但打算进行不同的修订可以完全互换。这将适合修复安全性先前发布的漏洞组装。

Phil Haack 有一个 .NET 版本控制系统的nice deconstruction，但实际上我认为他的担忧并不重要，因为根据我的经验，.NET/MS 版本控制系统仅真正用于技术调试/支持/跟踪目的，公众和项目管理通常会基于日期或虚构的营销版本号。

FWIW 我参与的每个 .NET 项目都由“X.Y.*”管理，即我们喜欢手动控制主要和次要是什么，但让系统控制构建和修订。

【讨论】：

【解决方案2】：

试试这个：

http://autobuildversion.codeplex.com/

【讨论】：

我们曾经使用过类似的方法，但发现用这种方法进行长期管理实际上非常困难。一方面，它不适用于持续集成，并对增量构建造成严重破坏。最终，我们改用 SVN 版本号作为内部版本号，从发布/错误跟踪的角度来看，这更有意义。

【解决方案3】：

我认为 Paul Alexander 的回答是正确的，但我想在您的 AssemblyInfo 文件中添加以下备注：

如果您使用1.0.2.*，请记住最后一位（由* 替换）是一个随机数因此如果您今晚构建1.0.2.*`，然后您明天早上再次构建它，第二个版本可以版本号低于您之前所做的构建。

【讨论】：

根据 MSDN ：“默认内部版本号每天递增。默认修订号是随机的。”
好吧，如果它是随机的，你会得到同样的异常情况：更高版本的版本号低于早期版本。
仅作记录，修订号不是随机的（不再）。现在，自动递增的构建和修订分别代表日期和时间。构建是自 01.01.2000 以来经过的天数，修订是当天经过的秒数除以 2（我相信由于 65535 的限制）。

【解决方案4】：

您需要考虑对程序集和文件进行不同的版本控制。当您更改程序集版本号时，现有代码可以在不重新编译的情况下使用它，但非常困难。我们仅在发生重大更改时更改程序集版本，以便我们可以轻松地发布小错误修复。

详细了解我们的Assembly Versioning 政策。

【讨论】：

如果您不更改主要和次要版本号，则程序集在 .net 框架（绑定）中被视为相同
这不是真的。当您使用强名称时，会考虑整个版本号。
您答案中的链接现已损坏。我相信现在是this one。

【解决方案5】：

我们以 2 为增量使用错误修复编号。奇数表示已发布小错误修复，偶数表示正在修复错误。显然，这在某些企业中很常见，即我所在的企业。

这个想法是为了识别意外发布，不知何故我喜欢这个想法。做事情，以便您很容易看到错误的事情。这并不是说奇数一定是非偶然释放，只是说它的概率很高。

【讨论】：

不应该反过来吗？因为，您系统中的 .0 表示开发版本，但 1.0.0 版本可能是真正的版本，不是吗？ :D 除此之外，我喜欢这个系统。说得通。我总是不确定什么时候增加这个数字（因为太早意味着有一个“错误”的版本，太晚意味着你不能用新的版本号提前测试）。

【解决方案6】：

感谢您的所有建议。

我决定使用以下。

我的项目有以下版本号：1.0.2.20。 1.：重大变化 0. :小改动 2.：错误修复 20 :Subversion 修订号

所以我在 assemblyinfo.c 文件中更改了以下内容

[assembly: AssemblyVersion("1.0.2.20")]

关于这个想法的任何建议，我很乐意听到。

非常感谢，

【讨论】：

如果您有许多不同的程序员在处理相同的代码，那么跟踪错误修复的数量会很困难。