是否有任何理由为.NET程序集使用一种版本控制方式????
我想知道使用除味道之外的任何一种风格是否有任何优点/缺点。
答案 0 :(得分：8)
时间的优势在于您可以获得不断增加的版本号和对时间戳进行编码。
使用更传统的数字的好处是人们更容易理解。例如，我们大致都知道“v2.1”的含义。
一般情况下，我建议使用时间，因为添加的信息很有用。其他数字的优势仅限于营销，无论如何你都可以这样做。
例如，为什么不同时使用la“v2.1.20090214”。现在，您可以在“构建”部分的major.minor部分和实用程序中进行营销。
答案 1 :(得分：4)
使用major.minor.revision方案的优点是语义。有一种更新这些数字的方法：
主要数字更改意味着新版本与旧版本不兼容，并且先前版本的任何依赖项将需要更改代码才能升级到新版本。
次要号码更改意味着新版本向后兼容以前的版本，但相对于以前的版本具有显着的增强功能。
每当修补程序应用于构建时，修订版号就会更新，这样就不会带来兼容性更改或引入更新的功能。在指定依赖关系时，您可以说您依赖于foo-1.0.0 - foo-1.99.999，并且请放心，您最终不会遇到破坏应用程序的软件包升级。
如果你开始使用更高版本的依赖项，比如foo-1.4.22，你应该将依赖项指定为foo-1.4.22 - foo-1.99.999，这样你就不会最终安装一个早于1.4.x的版本，可能缺少某些功能/增强功能。
答案 2 :(得分：3)
我将AssemblyVersion保留为“1.0。*”并删除任何AssemblyFileVersion。
然后我可以根据需要递增主要版本号和次要版本号，并自动设置默认的DateTime基本版本和修订版。
除非您有其他构建工具根据其他方案控制构建和修订号，否则我认为手动设置它们没有任何实际优势。
答案 3 :(得分：2)
使用时间/日期还有一个（除了那里已经提到过的其他答案）缺点：
如果您的开发团队分布在不同的时区，您永远不会确定相隔一小时的两个版本中的哪一个是较新的版本。除非您还要对时区进行版本控制或强制将日期/时间设置为例如GMT。
答案 4 :(得分：1)
我使用一些构建脚本来根据SVN版本更新我的修订版。这使得跟踪一个dll回到创建它的源代码变得微不足道。
时间比较棘手;您必须开始查看历史记录窗格 - 因为大多数源代码控制工具都有“获取修订”功能。
答案 5 :(得分：0)
为什么选择？您可以使用Major.Minor.YYMMDD.Revision之类的格式，并充分利用这两个世界。
修改 正如评论中所指出的，每个领域的范围有时会受到限制。在这种情况下，您可以使用Major.Minor.YMMDD.Revision。
希望你至少每10年更换次要版本！
答案 6 :(得分：0)
基于日期的版本编号的一个缺点是旧软件的负面感知。
虽然，我仍然使用它，因为它非常适合我的项目。