如果您的应用程序具有人们开发的公共API，那么您在以下方案中做了什么？
如果您发布了自己的服务包 应用程序你改变版本 组件数量？
同样更改版本 如果您提供热修复，请输入数字？
如果这样做，您是否为程序集重定向提供策略文件？或者如果您不在哪里，策略文件适合场景？我什么时候会选择不更改版本号或提供策略文件并更改版本？
答案 0 :(得分：2)
我们遵守规则，即版本号的前三部分或多或少是由营销产生的人为数字。模式类似于“Major.Minor.ServicePack”。 （Service Pack和hot fix之间的区别只是politcs。）但最后一个数字是由构建脚本自动插入的，并保留脚本运行的分支的最后一个更改的子版本修订版。通过这种方式，我们总能找到“野外”的任何二进制文件的确切代码库。
答案 1 :(得分：1)
保持版本号不变的原因与强名称程序集有关。
如果要允许已编译的应用程序使用更新的强名称程序集，则可能不会更改版本号，因为应用程序将需要与编译它的程序集相同的版本。
当然，只有在未修改程序集的接口时才会成立。
答案 2 :(得分：1)
如果公共API的方法等发生了变化，或者如果调用的行为发生了变化，客户端可能需要重写一些使用api的代码，则只需要更新版本号。
答案 3 :(得分：0)
Microsoft的方法是使用Major.Minor.BuildNumber.Revision。我建议自动生成和使用BuildNumber.Revision for Service Packs和Hot Fixes。我会手动修改并使用Minor内部版本号来扩展API。我会在以非向后兼容的方式更改内容或对功能引入重要（30％或更多）更改或扩展时手动修改和使用Major内部版本号。
杰夫阿特伍德实际上有一篇关于version numbering的石头时代的博客文章，这里有一个关于automatically incrementing版本号的问题，我喜欢answer that linked到{{ 3}}。