version - 未付费应用程序的日历对齐版本号

Question

我的团队正在处理的内部应用程序目前在一个版本上10.y.z.build_number。

在讨论下一个版本是否足够重要10.y+1.z.build_number时，10.y.z+1.build_number我建议我们可以保持简单并将版本号与日历保持一致。

例如，下一个版本是13.8.1.build_number2013 年 8 月的第一个版本。九月的版本是13.9.1.build_number.

暂时放弃了这个想法。

对于付费应用程序，我可以想象拥有第一个数字有助于轻松区分免费升级的版本和需要付费更新的主要版本。x+1.y.z将被支付，x.y+1.z将是免费的。

快速搜索后，我找到了 Jeff Attwood 的版本号中的内容，无论如何？.

然而，对于一个未付费的内部应用程序，我想不出与日历对齐的版本号的弱点，简单的美对我说。正如对 Jeff Atwood 帖子的评论之一所说：Microsoft Office 2003 是一个比 Microsoft Office 11 更有意义的名称。

问题：我的愿景是否被热情所笼罩，是否存在与日历对齐的版本号的已知问题？

Answer 1

对于内部应用程序，版本需要传达的信息是构建所述应用程序的源的修订或提交。

由于您可以访问管理该应用程序源的 VCS，因此该版本可以帮助报告错误，例如：“在修订 xxx 中找到”。
这比基于日期的标签更有价值，可以对其进行解释，以便找到显示需要报告的错误的源的确切版本。

您可以将其与您想要的任何版本策略结合使用标签：例如，git 可以基于 SHA1 + 标签生成唯一的版本号。看：

• " Deriving application build version from git describe- 如何得到一个相对简单的字符串？ "
• "用 git 模拟一个全局修订号"

但这个想法仍然存在：日期是由 VCS 或构建调度程序（如 Jenkins/Hudson/TeamCity）管理的元数据......它不必在应用程序的公共版本号中。

该版本号中需要的是允许获取构建该应用程序的确切来源的信息。