日期为软件版本号

软件开发人员通常不使用日期作为版本号，尽管YYYYMMDD格式（或其变化形式）看起来足够坚固可以使用。该计划有什么问题吗？还是仅适用于有限的“类型”软件（例如内部生产）？

在考虑用户需求以及软件和开发人员的需求时，您必须从几个不同的角度来考虑这一点。

通常，只要客户知道他们正在运行更新的产品（即，Product 2012比Product 2010更新），他们就不会在乎该软件的版本号。如果有可以部署的补丁程序（例如，Product 2012，Update 10），则为最新。因此，从客户品牌的角度来看，我倾向于使用命名版本（例如Windows XP，Windows Vista），然后是可能由用户安装的严格顺序的补丁程序。

话虽这么说，编写检查用户容易的东西的软件往往会使引擎盖下的代码更难编写。因此Major.Minor，仅由于您可以进行简单的数字比较以检查是否有最新内容，我倾向于使用简单版本方案，如下所示：

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

不过，将其放在上下文中，我通常不在乎次要数字有多大（即1.1024），这使得上述系统能够继续成功运行。通常，修订号只对内部开发有意义，实际上我什至没有真正看到它们对事情的影响远不只是给事物提供一个额外的数字来跟踪。

但是，以上两种方案实际上仅不适用于正在使用连续部署的环境（即Stack Exchange），在这种环境下，我倾向于使用某种日期，后跟修订号，就像在Stack Exchange上使用的那样网站。这样做的原因是，在连续部署环境中版本会经常更改，并且您可能会在同一天运行多个版本的代码，这可以证明修订版本号和当前日期与任何可破坏内容的日期一样好甚至更多。从理论上讲，您可以对所有内容使用修订号，但使用当前日期可以使您在内部跟踪主要的里程碑，从而使事情更容易讨论。

使用日期的问题在于，规格是根据计数数字而不是到期日期写的。

“该功能应在版本1中。其他功能应在版本2中。”

您无法在规格中提及日期，因为可能会错过发布日期。

如果您没有需要预先确定不同版本的正式流程，则可以使用日期；您无需在组合中添加其他数字。

版本号不太可能包含日期，因为它们的上下文与规范有关。
内部版本号可能会包含日期，因为它们的上下文与构建的时间相关。

尽管此方法具有您所描述的优点，但是如果将日期用作版本号，则存在某些缺点：

• 基于日期的版本是固定的。在v2.1.3中，您可以看到版本号，子版本号和子子版本号。使用20110119，您只能看到它的编写时间。您可以按月对基于日期的版本进行分组，但它仍然不会告诉您任何信息。您可能需要花几个月的时间来修复小错误，然后花两周的时间进行繁重的编码才能发布主要版本。日期不会告诉您，普通版本号会告诉您。

• 如果您确实确实需要每天更改版本以及可能的发行版号，则可以表明您没有适当的发行过程，但是每个人都可以随意更改内容，并在需要时将其升级到生产服务器。如果是这样，则说明您的过程存在问题，并且使用其他版本号架构无法解决该问题。

版本通常用于传达有关该软件的特定版本与先前版本有何不同的信息。因此，例如，如果从Acme的1.0升级到2.0，则这是一次重大升级，理论上进行了重大更改。

另一方面，从1.0升级到1.1是一次较小的升级，理论上进行了较小的增量更改和错误修复。

尽管可以混合使用，但很难以日期格式表示。例如，v1.0.YYYY.MMDD

在没有重复其他答案的好主意的情况下，我心中有一个尚未解决的问题。

如果您碰巧在早期版本（用于向后兼容）和新版本（用于不兼容的现代化）之间进行了分叉，则无法通过版本号来区分它们。

例如，Linux内核在2000年左右被分叉到旧的2.4.x分支中，该分支现在可能仍受支持，并计为2.4.199，而新版本多年来一直是2.6，并且是2.6.32。对于较旧的系统，但对于最新的内核为3.2。

如果您有关于发行的文档，则将信息加倍并告诉人们，20120109版本于2012年1月9日发行。嗯 但是，如果发现了最后一刻的错误，并且发布被推迟了一个星期，但是提到名称的文档已经准备好了，也许已经印制了，新闻信息就出来了等等。现在，如果版本20120109到达2012/01/13，则存在问题，这是有问题的。

在SQL中，经常讨论ID是否应携带语义信息的问题，其结果始终是：避免像地狱一样！您正在创建不必要的依赖项。它不会有好处。

Ubuntu的04/10方案在2006年出现了问题，当时6.04版本被延迟并​​变为6.06。在3000年，很快就会出现下一个问题！:)

实际上，有许多软件包确实使用日期作为版本。想到Ubuntu，它们的版本是YY.MM。并且Microsoft Office产品的内部版本号也是内部版本日期的编码。Jeff Atwood写了一篇有关版本编号的Coding Horror博客文章，其中包括以下建议：

尽可能使用简单的日期而不是版本号，尤其是在产品的公共名称中。并且，如果您绝对肯定地在内部必须使用版本号，则无论如何都要使它们成为日期：请务必在版本号中的某个位置编码构建日期。

在我看来，只要您保持一致并能够从构建版本号开始（无论它是什么）并从版本控制系统中调用进入该构建的所有工件，这都没有关系。用户通常根本不关心版本信息，而是系统提供的功能。版本信息仅对开发人员具有实际价值。

使用语义版本控制-这样一来，您就可以了解版本之间进行的那种更改，而无需检查代码本身：http : //semver.org/

使用版本号是一种显示更改有多大的方法

例如，2.4.3可能意味着版本2是整个系统的主要更改。.4是一个小更新。最后一个.3是对该版本的一个小错误修复。这样，就可以轻松识别每个版本之间发生了多少变化。

话虽如此，我仍然看到许多人使用日期或SCM修订号作为版本号，只要您有某种方式可以追溯到支持发行说明和该发行版范围内的文档，就没有真正的问题。

这里已经有一些不错的答案，但是我想指出一个使用日期非常有意义的情况：小型库或代码片段，其中的代码可能会经常更新，但是很少，并且没有一个版本与以前的版本存在明显差异一。

换句话说，我所谈论的情况是没有实际的“版本号”，但基本上是一种准每日的存储库转储。

当我遇到这类问题时，我通常会欢迎这种选择，因为对于我来说，我使用的是相对最新的脚本/库而不是特定版本，对我来说更有用。

将日期作为版本号对市场营销很有用。如果人们使用“ Windows NT 5.0”，他们可能不会意识到它已经过时。但是，如果人们仍在使用“ Windows 2000”，他们会立即知道它已经是12年的操作系统了，并被鼓励进行升级。

但是，这确实使区分“主要”和“次要”更新变得更加困难。

使用日期作为版本号的问题

这里的答案很好，但是我没有看到有人使用日期来解决此问题：用户无法确定修改的频率。

我要说的是，我可以说Windows 3.1和Windows 7相距遥远...也许不兼容。Windows 95和Windows 2000仅向我介绍了该产品推出的年份。

例如，对于Python，我知道版本2.7.2是从2.4.6演变而来的。如果进一步看，我发现2.4.6版本已于2008年12月19日发布；该版本已发布。该版本2.7.2于2011年6月11日发布。由此，我可以对产品的稳定性（即发布频率）形成看法。

相反，如果Python使用发布日期，那么我将不知道这些产品可能如何连接。由于还会在2011年6月11日发布Python 3.1.4（与Python 2.7.2相同），因此还会造成进一步的混乱。

简而言之，我认为日期转换本身并不有价值。

由于其他人已经描述过的原因，我不喜欢这个想法。只需使用major.minor.bugfix方案-大多数人这样做是有原因的。

但是，无论您做什么，都可以：选择一种版本命名方案，并坚持使用。不要像Windows那样做，因为Windows在每个发行版中都会更改方案。并且不要像Android那样做，因为每个版本都有一个API版本号（8），一个用于市场营销的版本号（2.2）和一个愚蠢的名称（Froyo）。

日期作为版本

如果您的产品未售出，则仅使用日期可能会有用。如果您出售它并升级给客户，他们想购买具有特定功能的模型。如果此型号有明确的名称，则在升级时出售它们会更容易，它的名称并不重要，例如，没有人真正购买2012年1月20日的福特汽车，而他们都希望起亚Model。软件也是如此。给出硬模型名称和版本意味着它具有与旧模型不同的功能。对我来说，约会并不能解决这个问题，它说我做到了，但它可能没有新功能。

我们使用的方案

我没有宣称我们的系统可以像上面那样创建清晰的品牌。 现在，我们使用四部分方案。版本号，状态，日期和校验和。

1200_GLD_120120_F0D1

这可能会缝在顶部，但它使我们可以为工程师使用1200版的构建版本，我们按日期区分它们。该州会告诉人们它是内部测试版本，客户补丁程序构建版还是黄金发行版。校验和是新的，它使工程师或客户可以验证他们是否确实从我们的发行版中下载了正确的校验和。

所以我们可能有一个序列

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

我们通常仅将主要版本号称为客户，即“ 12”，但除非他们需要修订，否则客户将获得12的最新黄金版本，即1200_GLD_120120_F0D1。

假设有些客户使用您产品的第二版，有些客户已升级到第三版，而升级并不是一个轻易决定的事情。

假设第二版的最新版本为2.3.2，第三版为3.0.3。现在，您发现了绝对需要修复的漏洞，因此可以在同一天发布2.3.3和3.0.4。您能看到发布日期完全无关吗？您可能在2013年停止了第二版的工作，此后仅发布了一些基本的错误修复。日期与版本号无关。

我认为效果很好。我将其用于一些内部软件（yyyy.mm.dd）和一些我发布的开源软件。

它可能并非在所有情况下都有效。

从技术上讲，它不能使用日期作为版本号，但是可以为客户显示日期号。例如，macOS 16.7.23 ---表示：23/7/2016

我认为技术不是问题，问题在于感觉如何？如果使用可以使软件存活，存活的日期编号，就像一个生日号的人一样。每年我们都在成长，就像软件在不断成长。

楼号看起来像机器，机器，没有生命，没有生命。