是否有任何理由对 .NET 程序集使用一种版本控制风格而不是另一种？？？？
我想知道除了口味之外，使用这两种风格是否有任何优点/缺点。
Felipe Angriman
问问题
6736 次
7 回答
9
时间的优势是您可以获得不断增加的版本号并编码时间戳。
使用更传统的数字的好处是人们更容易理解。例如，我们都大致知道“v2.1”是什么意思。
一般来说，我建议使用时间，因为添加的信息很有用。其他数字的优势仅用于营销，为此您无论如何都可以这样做。
例如，为什么不同时拥有两者，比如“v2.1.20090214”。现在您在major.minor 部分中有营销，在“构建”部分中有实用程序。
于 2009-02-22T21:48:17.790 回答
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，它可能缺少一些功能/增强功能。
于 2009-09-01T04:52:13.870 回答
3
我只是将 AssemblyVersion 保留在“1.0.*”并删除任何 AssemblyFileVersion。
然后，我可以酌情增加主要和次要版本号，并自动设置默认的 DateTime 基础构建和修订。
除非您有根据其他方案控制构建和修订号的替代构建工具，否则我认为手动设置它们没有真正的优势。
于 2009-02-22T21:53:23.033 回答
2
使用时间/日期还有一个缺点（除了这里其他答案中已经提到的）缺点：
如果您的开发团队分布在不同的时区，您将永远无法确定相隔一小时构建的两个版本中的哪一个是较新的版本。除非您还对时区进行版本化或强制日期/时间使用例如 GMT。
于 2009-02-23T07:15:00.907 回答
1
我使用一些基于 SVN 版本更新我的版本的构建脚本。这使得将 dll 跟踪回创建它的源代码变得微不足道。
时间比较棘手；您必须开始查看历史记录窗格——因为大多数源代码控制工具都有“获取修订”功能。
于 2009-02-22T22:34:53.840 回答
0
为什么选择？您可以使用 Major.Minor.YYMMDD.Revision 之类的格式，并获得两全其美的效果。
编辑 正如评论中指出的那样，有时每个字段的范围都受到限制。在这种情况下，您可以使用 Major.Minor.YMMDD.Revision。
希望您至少每 10 年更改一次次要版本！
于 2009-02-22T22:40:52.360 回答
0
基于日期的版本编号的一个缺点是对旧软件的负面看法。
虽然，我还是使用它，因为它非常适合我的项目。
于 2009-02-22T22:53:55.150 回答