major.minor.build.revision 版本风格与 year.month.day.whatever 版本风格答案

【问题标题】：major.minor.build.revision versioning style vs year.month.day.whatever versioning stylemajor.minor.build.revision 版本风格与 year.month.day.whatever 版本风格
【发布时间】：2010-10-09 05:16:41
【问题描述】：

是否有任何理由对 .NET 程序集使用一种版本控制风格而不是另一种？？

我想知道除了品味之外，使用这两种风格是否有任何优点/缺点。

【问题讨论】：

标签： .net deployment assemblies version

【解决方案1】：

时间的好处是您可以同时获得不断增加的版本号和对时间戳进行编码。

使用更传统的数字的好处是人们更容易理解。例如，我们都大致知道“v2.1”是什么意思。

一般来说，我建议使用时间，因为添加的信息很有用。其他数字的优点是仅用于营销，为此您无论如何都可以这样做。

例如，为什么不两者都有，比如“v2.1.20090214”。现在，major.minor 部分中有营销，“build”部分中有实用程序。

【讨论】：

如果您使用日期作为版本号，请使用 YYYYMMDD 格式。它是唯一几乎任何人都可以明确阅读的，并且具有按正确顺序进行词汇排序的优势。
（对于我们当中的狭隘人士来说，一些国家以 MM-DD-YYYY 格式写他们的日期，而其余大部分理智的单词则以 DD-MM-YYYY 或 YYYY-MM- DD 格式。）
请注意，在 Win32（以及 .NET）上，每个组件的版本号限制为 16 位，因此无法将 20090214 作为一个组件。

【解决方案2】：

使用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 的版本，可能缺少某些功能/增强功能。

【讨论】：

【解决方案3】：

我只是将 AssemblyVersion 保留为“1.0.*”并删除任何 AssemblyFileVersion。

然后我可以酌情增加主要和次要版本号，并自动设置默认的 DateTime 基础构建和修订。

除非您有其他构建工具根据其他方案控制构建和修订号，否则我认为手动设置它们没有真正的优势。

【讨论】：

我正在做同样的事情。

【解决方案4】：

使用时间/日期还有一个缺点（除了此处其他答案中已经提到的）缺点：

如果您的开发团队分布在不同的时区，您将永远无法确定相隔一小时构建的两个版本中的哪一个是较新的版本。除非您还版本时区或强制日期/时间在例如格林威治标准时间。

【讨论】：

【解决方案5】：

我使用一些构建脚本来根据 SVN 版本更新我的版本。这使得将 dll 追溯到创建它的源代码变得微不足道。

时间比较复杂；您必须开始查看历史记录窗格——因为大多数源代码控制工具都有“获取修订”功能。

【讨论】：

【解决方案6】：

基于日期的版本编号的一个缺点是对旧软件的负面认知。

尽管如此，我还是使用它，因为它非常适合我的项目。

【讨论】：

并不总是不利的。这种负面看法可以用来推销你的新版本。

【解决方案7】：

为什么选择？您可以使用 Major.Minor.YYMMDD.Revision 之类的格式，并获得两全其美的效果。

编辑正如 cmets 中所指出的，有时每个字段的范围都受到限制。在这种情况下，您可以使用 Major.Minor.YMMDD.Revision。

希望您至少每 10 年更改一次次要版本！

【讨论】：

如果我错了请纠正我，但根据 MSDN 在“msdn.microsoft.com/en-us/library/…”的说法，每个组件必须是 0 到 65535 之间的数字。YYMMDD 太大了。 "Major.Minor.YYYY.MMDD" 会合适，但可以接受 :-(