首先，我认为这个论坛不适合我的问题，所以如果发错地方，请原谅并放在适当的地方。我没有找到适合我的问题的论坛。
我开发了一个 C# 应用程序（Win Forms）。现在我需要处理它的版本编号。我无法弄清楚最好的方法是什么。我希望版本号很简单，例如 1.2 或 1.2.1。我阅读了有关 SVN 版本的信息，但在现阶段这似乎也有点令人困惑。应用程序有不同的版本类型 - 1 有安装程序，1 没有安装程序。
我认为发布版本和开发版本应该是一样的-如果我错了，请纠正我。应该自动处理还是手动更改？处理应用程序版本编号的最佳、简单和容易的方法是什么？
【问题讨论】：
标签： c# winforms versioning
我们使用major.minor[.build[.revision]]。我们给出以下语义：
主要 = 主要版本。 （有点大的变化，甚至可能是 UI 刷新）。 次要 = 作为中等更改集。 （可能是新的内部流程或引擎的重构）。
关于构建和修订：
0 - 表示它的 alpha 阶段。
1 - 测试版。
2 - 发布候选。
3 - 生产。
所以，如果您的应用在 3.2.1.0 上。您知道您正处于 3.2 版本的 alpha 阶段。等等。
注意：虽然包含修订似乎有点大，但我们认为这是一个很好的做法，因为如果我们发现一些错误或意外行为，我们只需修复并增加修订而不是构建。
【讨论】：
<br/> 在答案的正文中插入一个新行。
我认为 - 这来自我的经验，而不仅仅是一个想法 - 你应该使用 4 部分版本编号 - 非常类似于 @Randolf。但是，我会对部件和版本进行不同的定义。
major - 当版本是新版本，与没有升级过程的先前版本不兼容，或者当构建/开发平台发生变化时（因此从 .net 2.0 迁移到 .net 4.0 将计数），这应该增加。
minor - 当应用程序底层的数据结构发生变化时（无论这是否是数据库），这应该增加。这意味着将需要构建或更新数据，这对客户来说表明升级可能需要的工作级别。
build - 每当生成完整的生产版本时，它都应该始终递增，作为候选发布版。
revision - 这应该针对每个构建进行更新，并用于修复候选版本的错误。
这意味着您可以通过版本号准确识别该版本中有哪些更改和修复，这对于支持至关重要。
手动或自动 - 此路径意味着手动更新，这对于您识别发布包含的内容很重要。
发行版号和开发版号通常应该相同，因为只有在为潜在发行版进行构建时，版本号才应该递增。话虽如此，您还应该确保您可以在任何受支持的版本上进行开发，如果新版本正在测试中，该版本可能低于当前的开发版本。
【讨论】：
许多人认为，令人沮丧的是，.Net 似乎认为构建编号是“错误”的方式。 AssemblyInfo 将内部版本号指定为[Major][Minor][Build][Revision]，这对我来说没有任何意义。当然，每晚的构建比规范的修订更频繁，因此是“最小”的变化吗？不过我不会与框架抗争，所以我只能忍受它。
也许这与美国人以错误的顺序指定日期的现象是同一个根本原因。同样，常识会始终如一地规定大->小。
关于从概念上组织这一点，我想说一个由四部分组成的内部版本号的每个部分都应指示适当幅度的最新更改；即：
重大：应用程序的重大升级，如果它是商业项目，您希望用户为此付费。用户应该会面临基础架构问题，例如服务包和新的 .Net 版本；
次要：大量错误修复和更改请求，将满足“小功能”的描述。可以说应该已经在程序中的任何内容都可以滚动到次要版本中；
Build：个人选择，但对我来说，这将是唯一的内部版本号。如果您从集成服务器获取二进制文件，这可能会达到数万个。可能是每晚构建，但也可以在 PM 说“开始”时按需构建。内部版本号应唯一对应于在集成服务器上启动完整生产版本的事件。
修订：至少在概念上应该与规范的修订相对应。通常会匹配更改日志中的项目，即所有增量更改，包括更改请求 x。
【讨论】：
在BuildMaster中，我们考虑#.#.#.#版本号格式来表示：
[major version].[minor version].[maintenance version].[build number]
由于大多数情况下我会从我们的博客中反省信息，所以我只给你一个我的同事写的文章的链接：http://blog.inedo.com/2011/03/15/release-numbering-best-practices/
在更新您的版本号时，我会将本地开发版本保留为 0.0.0.0，让您的自动构建过程担心编号。
【讨论】：