我的团队正在处理的内部应用程序目前使用的是10.y.z.build_number版本。
在讨论期间，如果下一个版本对于10.y+1.z.build_number来说足够重要，或者它应该是10.y.z+1.build_number，我建议我们可以保持简单并将版本号与日历对齐。
例如，下一个版本将是13.8.1.build_number，代表2013年8月的第一个版本。九月一个版本将是13.9.1.build_number。
这个想法暂时被抛弃了。
对于付费应用程序，我可以想象，使用第一个数字可以轻松区分具有免费升级的版本和需要付费更新的主要版本。 x+1.y.z将被支付，x.y+1.z将免费。
快速搜索后，我找到了Jeff Attwood的What's In a Version Number, Anyway?。
然而，对于无偿的内部应用程序，我无法想到日历对齐版本号的弱点和简洁之美对我说话。正如Jeff Atwood的帖子中的一篇评论所说： Microsoft Office 2003是一个比Microsoft Office 11更有意义的名称。
问题： 我的愿景是否被热情蒙上阴影，是否存在日历对齐版本号的已知问题？
答案 0 :(得分：0)
对于内部应用程序，版本需要传达的信息是修改或提交构建该应用程序的源。
由于您可以访问管理该应用程序源的VCS，因此该版本可以帮助错误报告，例如：“在修订版xxx中找到”。
这比基于日期的标记更有价值，可以对其进行解释，以便找到显示需要报告的错误的源的确切版本。
您可以将它与您想要的任何版本策略结合使用，例如：git，例如，可以根据SHA1 +标记生成唯一的版本号。参见：
git describe - how to get a relatively straightforward string?”但是这个想法仍然存在：date是由VCS管理的元数据或者像Jenkins / Hudson / TeamCity这样的构建调度程序......它不必是应用程序的公共版本号。
该版本号需要的是一个信息，允许获取构建该应用程序的确切来源。