我一直在为版本控制软件苦苦挣扎。 我不是在谈论命名约定，而是在谈论如何在构建系统中实际应用一个版本，直到发布。
我一般用major.minor.maintenance-[release type] 即 1.0.2-rc1
问题在于管理版本号。我尝试了很多方法（将其粘贴在构建文件、属性文件、数据库等中），但我没有找到任何真正有效的方法。
我想出的最接近的方法是使用我在此处记录的 Jira： http://blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html
我想知道是否有人对此有任何好的想法。 另外，想知道人们如何处理发布版本....即，如果我发布/部署版本 1.0.0-rc1 在此版本中发现错误然后登录到 1.0.0（下一个/生产版本）。
【问题讨论】：
Microsoft 使用 <major>.<minor>.<patch>-<build number>（或变体）。
我喜欢使用<major>.<minor>.<buildnumber>
【讨论】：
在我工作的地方，我们使用 Maven 系统：artifact[-major-minor-revision][-SNAPSHOT]，它允许我们开发“进行中”的版本，这些版本可以随时更改 (SNAPSHOT) 以及那些有被正式发布。一些例子是：
email-services-1.0.0-SNAPSHOT.jar
如果其中包含 SNAPSHOT，那么它还没有通过全套测试，或者只是一个开发者实验。如果它没有 SNAPSHOT，那么它就是一个候选版本。我们维护一个发布候选者的存储库，一旦测试人员对它感到满意，最新的将被发送以进行部署。
所有这些都可以通过 Maven 下的构建文件中的一些简单条目来管理。见Maven2 tutorial
【讨论】：
现在这可能是一个死帖，但无论如何我都会加两分钱。我认为内部版本号应该对每个看到它的人都有意义。所以我个人认为这是给版本命名的好方法：
major.minor.patch.revision - 例如1.1.4.2342
主要/次要数字是不言自明的。但从第三个数字的角度来看，它仍然需要对客户有意义。我已经向您发布了这个新版本，客户先生，但它不值得一个新的次要号码，因为我们只是修复了一些错误。所以我们增加了补丁号。
第 4 个数字通常对客户绝对没有任何意义，因此您不妨让它对您和您公司中看到它的任何其他人都有用。所以对我们来说，这个数字就是 SVN 版本号。它准确地告诉我们哪个版本负责该版本，以便我们可以随时将其拉出以重新创建它。分支代码显然也能做到这一点，但不是 100% 确定的。
此外，全数字版本号的另一个优点是它可以轻松集成到几乎所有连续构建系统中。
无论如何，这是我的两分钱。
【讨论】：
+1 关于 Jira/Bamboo 解决方案。关于构建的唯一附加信息（出于我的目的）是 Subversion 版本，尽管标记操作是我想要的 80%。
手动维护发布/版本信息是一件非常痛苦的事情。让 JIRA 驱动它是个好主意。
关于最后一个问题，关于记录错误/缺陷的位置和releasing 版本：
通过 JIRA 进行管理的美妙之处在于，添加版本、生成更改日志等可以很好地自动化。
【讨论】：
我们还使用<major>.<minor>.<buildnumber>，并在我们的构建服务器上使用 CruiseControl/(.Net) 进行管理。并使用 Wix 和 CruiseControl Config 管理主要次要编号 - 仍然手动增加这些次要编号 - 但构建号在构建服务器上时会自动发生。我相信你也可以设置一个规则来自动增加主要/次要 - 我们只需要手动执行此操作，以便开发人员在需要命名特定版本级别时进行有意识的思考。
【讨论】：
Major.Minor.BuildDateNumber.DailyBuildNumber
Major 和 Minor 由我们设置，在我们认为合适的时候手动增加它们。
BuildDateNumber 是自项目开始以来的月数乘以 100，再加上当月的天数。
DailyBuildNumber 每天午夜后每次构建都会递增，从零开始。
例如7 月 10 日发布 5.2 的第 4 个版本，该项目于当年 1 月 1 日开始，将有版本号
5.2.710.3
这都是Version task in Nant为我们计算的。
这样可以保持版本号的唯一性，还可以让我们快速计算构建安装的时间。
【讨论】：